[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: String class: hack for ORP 1.0.9
From: |
David P Grove |
Subject: |
Re: String class: hack for ORP 1.0.9 |
Date: |
Tue, 12 Jul 2005 11:07:07 -0400 |
Guess I'm showing my bias ;-) It is very easy to get the right thing to
happen in Jikes RVM...
In general, you are right about native methods being a barrier to JIT
optimization (btw there was an interesting paper in VEE'05 last month by
Stepanian et al on a system that can inline native methods and their JNI
callbacks into JITed code).
Arraycopy is just a very special case...it shows up as a bottleneck on
enough benchmarks that many optimizing JITs will treat it as an
intrinsic function (ie, there is a native method implementation in the VM
for use by interpreted code, but the JITed code won't actually call it).
In some slightly funky way of looking at the world, native methods like
arraycopy are a special case where Java-in-Java and C-based VMs end up in
pretty much the same place. It's a "native" method that the JIT really
needs to grok to get good performance. In Java-in-Java that happens
without much extra effort. In other VMs, you end up building up support
for a set of performance critical intrinsics so that the JIT can
completely understand their semantics and then implement them in a more
optimal fashion than simply calling the backing native method. I should
have made it more clear that I was talking about arraycopy in particular,
not native methods in general.
--dave
Archie Cobbs <address@hidden> wrote on 07/12/2005 10:24:10 AM:
> David P Grove wrote:
> > So, I'm having a hard time seeing how this "optimization" actually
makes
> > the code faster under any reasonable assumptions of what an optimizing
JIT
> > is going to do. It seems mostly harmless to have it (although it
makes
> > the method larger, and thus a slightly less attractive candidate for
> > inlining), but if it actually buys you any measurable speedup on a
"high
> > performance" VM, then you should really take a hard look at your
VM/JIT
> > and find out why they didn't do a good job on the "unoptimized"
version in
> > the first place. clone() on an array is just a short hand for a new
> > followed by an arraycopy, and the new followed by arraycopy idiom
shows up
> > all over the place so you need to do a good job on it.
>
> Not all VM's are high performance I guess :-)
>
> [I'm sure you know all this already but here goes..]
>
> E.g., on many VM's VMSystem.arraycopy() is a native method, and they
> can't optimize "into" that method. So all the normal type checking,
> array bounds checking, and array compatibility checking will be done
> by that native code in all cases, even though in this case we know
> it's not necessary.
>
> With array clone(), also typically a native method, none of that
> checking is ever needed.
>
> This is a good example of the advandages of a JVM written in Java
> (a coincidence? :-) There is no "optimization barrier" into "native"
> code like System.arraycopy().
>
> -Archie
>
>
__________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com