[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cp-patches] Re: String class: hack for ORP 1.0.9
From: |
Archie Cobbs |
Subject: |
[cp-patches] 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
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com