[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 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.


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 
> > the code faster under any reasonable assumptions of what an optimizing 
> > is going to do.  It seems mostly harmless to have it (although it 
> > the method larger, and thus a slightly less attractive candidate for 
> > inlining), but if it actually buys you any measurable speedup on a 
> > performance" VM, then you should really take a hard look at your 
> > 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        *

reply via email to

[Prev in Thread] Current Thread [Next in Thread]