harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [drlvm][jit][ia-32]register-based fast calling convention
Date Fri, 17 Nov 2006 04:22:22 GMT
Hi Pavel,

Thank you for your interest.

Pavel Ozhdikhin wrote:
> Do you know if other VM use register-based fast 
> calling  convention and what gain we can get from it? Can we see that
> using micro-benchmarks?
Well, I guess this is quite low level details of an implementation, I 
did not hear much info. Some infos [1][2] shows that HotSpot uses some 
kind of register-based convention, but without much details on it.

As for the gain - well, it's hard to predict, and with all the the 
standard disclaimers like YMMV :-), I would expect the PUSH/POP overhead 
elimination may add about 20%.
Again, on some workloads and YMMV. :-)

This is why I'm going to make the things tunable - to measure the exact 
gain when it's implemented.


[1]
HotSpot porting guide, thought it's actually about ARM and CLDC.
http://java.sun.com/javame/reference/docs/cldc-hi-1.1.3-web/doc/porting/html/ARM-FP.html
[2] It's about server HotSpot.
Some notes in global register allocator section (12) tend me think they 
use registers for passing arguments
http://www.usenix.org/events/jvm01/full_papers/paleczny/paleczny.pdf


-- 
Thanks,
   Alex

> 
> 
> On 11/16/06, Slava Shakin <vyacheslav.p.shakin@gmail.com> wrote:
>>
>> Alex,
>>
>> It's great you're going to do that. I like the proposal.
>>
>> >     - make it possible to switch between existing and new conventions
>> > for investigation and tuning purposes
>>
>> I think such configurability is a very important feature as we lose
>> nothing
>> but acquire both more opportunities for tuning and some performance win
>> even
>> with the current optimization set. IMO it is important to expose as many
>> options for tuning as possible because even if the proposal doesn't
>> immediately bring considerable boost we might well expect more from
>> synergy
>> with future optimizations and non-default options of existing ones.
>>
>> -- 
>> Thanks,
>> Slava Shakin.
>>
>>
>> "Alex Astapchuk" <alex.astapchuk@gmail.com> wrote in message
>> news:ejf6do$fv2$1@sea.gmane.org...
>> > Hi all,
>> >
>> > Among other things listed on the JIT Dev tasks, there is a need for
>> > calling convention (CC) fix-up for IA-32 [1].
>> >
>> > Current problems are:
>> >
>> > 1. The calling convention(s) used are stack-based - this adds a memory
>> > access overhead on calls.
>> > 2. The convention currently used for managed code neither allow to pass
>> > float-point values on XMM registers, nor it provides callee-saved XMM
>> > registers.
>> > 3. FPU stack is used to return float/double values
>> >
>> >
>> > Both 2) and 3) affect register allocation for float point values in a
>> > bad manner.
>> > Fixing even the 1) looks promising for hot vm helpers like monitor
>> > enter/exit and resolve_interface_vtable.
>> >
>> > So, I'm going to implement register-based calling convention for IA-32.
>> >
>> > The current proposal is:
>> >     - make it possible to switch between existing and new conventions
>> > for investigation and tuning purposes
>> >     - implement 2 calling conventions:
>> > 1. well known standard fastcall (fisrt 2 params on ECX+EDX, the
>> > rest is on stack)
>> > 2. DRLVM-specific convention: which involves ECX, EDX (and may
>> > be EAX) for integer/parameters passing and also use XMMs for
>> > float-point parameters and produce callee-save XMMs.
>> >
>> > The #1 may be used to call internal C-based helpers. It may also be 
>> used
>> > to call VM helpers where XMM callee save regs may add unnecessary
>> > overhead on the helper itself. The example I can think of is
>> > resolve_interface helper - preserving XMMs there looks overkill.
>> >
>> > #2 will help to speed-up managed code both call-intensive and (I hope)
>> > FP-intesive - together with register allocator tuning.
>> >
>> >
>> > Any comments are welcome.
>> >
>> >
>> > [1]
>> >
>> http://wiki.apache.org/harmony/JIT_Development_Tasks#head-bffdfbc80108641ca9a8bc29ea871c67fb3b82b9

>>
>> >
>> >
>> > --
>> > Thanks,
>> >   Alex
>> >
>> >
>>
>>
>>
>>
> 




Mime
View raw message