[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: Archie Cobbs
Subject: Re: String class: hack for ORP 1.0.9
Date: Tue, 12 Jul 2005 09:24:10 -0500
User-agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041129

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 Cobbs      *        CTO, Awarix        *

reply via email to

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