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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
>
>
