Re: String class: hack for ORP 1.0.9

[Archie Cobbs]

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