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