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 <[EMAIL PROTECTED]> 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



_______________________________________________
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Reply via email to