Search |
||
JDK7 do escape analysis by defaultPosted by forax on October 6, 2009 at 1:56 PM PDT
During the JVM Summit, I was doing some tests for
my presentation with the latest
jdk7 binaries
when I've seen some *BIG* performance improvement between jdk7 b71 and jdk7 b72.
With a quick micro-benchmark, it's even better, as always :)
class DoubleSlot {
final int value1;
final int value2;
public DoubleSlot(int value1, int value2) {
this.value1 = value1;
this.value2 = value2;
}
}
static int slotValue(DoubleSlot slot) {
return slot.value1 + slot.value2;
}
static int sum(int[] values) {
int sum = 0;
int length = values.length;
for(int i=1; i<length; i++) {
DoubleSlot slot = new DoubleSlot(values[i-1], values[i]);
sum += slotValue(slot);
}
return sum;
}
static void test(int[] values) {
long start = System.nanoTime();
int value = sum(values);
long end = System.nanoTime();
System.out.println("time "+(end-start)+" "+value);
}
public static void main(String[] args) {
int[] values = new int[1000000];
for(int i=0; i»
Comments
Comments are listed in date ascending order (oldest first)
... will eventually be available in JDK6 too
Submitted by stefanz on Wed, 2009-10-07 14:11.
To my understanding, Escape analysis with respect to scalar replaceable object allocations from the heap is available since build 1.6.0_14
http://java.sun.com/javase/6/webnotes/6u14.html
Does/will EA get applied by
Submitted by damonhd on Mon, 2009-10-12 01:57.
Does/will EA get applied by the C1 compiler?
(I've just started using the C1-only 'embedded' SE Sun HotSpot JRE!)
Rgds
Damon
EA is not done by C1
Submitted by forax on Mon, 2009-10-12 02:52.
Hi Damon,
Escape analysis is a C2 feature only. Will it be included in C1 ? I don't know. Rémi Great start, but
Submitted by krausest1 on Sat, 2009-10-10 04:06.
I hope http://bugs.sun.com/view_bug.do?bug_id=6853701 gets fixed soon. Then my benchmark will improve too ;-)
Great but not perfect
Submitted by jaanvajakas on Fri, 2009-10-23 15:34.
Escape analysis is a great feature indeed, as it can alleviate the dilemma between writing fast code or flexible, object-oriented code. For example, knowing that an array wrapped into a temporary list object using Arrays.asList is as fast as accessing the array itself, one would never have to think whether to choose a List or an array when making an API for one's own components, as a List is far more flexible.
I made a benchmark with two classes: one, named EscapeAnalysisTest, was the same as in the benchmark in the blog, except that I replaced the time printing statement System.out.println("Time "+(end-start)*1E-6+" ms. Checksum: "+value);
for better readability. In the other one, named NoEscapeAnalysisNeeded, I removed the class DoubleSlot and replaced the sum method with the following one:
static int sum(int[] values) {
The results are following (on my AMD Sempron 3000+ with 64-bit openSuse 11.1 with Sun's 32-bit Java 1.6.0_15): java -server EscapeAnalysisTest had times around 49 ms, java -server -XX:+DoEscapeAnalysis EscapeAnalysisTest had times around 6.0 ms (8 times improvement!) and java -server NoEscapeAnalysisNeeded had times around 4.8 ms independent of the -XX:+DoEscapeAnalysis option.
I also tried 64-bit openjdk (containing OpenJDK 64-Bit Server VM 14.0-b16) on the same machine: java -server EscapeAnalysisTest improved to 43 ms and NoEscapeAnalysisNeeded improved to 3.4 ms but java -server -XX:+DoEscapeAnalysis EscapeAnalysisTest stayed at 6.0 ms.
So although escape analysis already provides a big performance boost, for some reason code with objects eliminated by EA is still not as exactly as fast code without objects in the first place. I guess here is a little room for further improvement. |
||
|
Will also become available in JDK6