JDK7 do escape analysis by default
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.
A quick look to the summary of changes, hum,
Escape Analysis is now enabled by default.
On my tests, I got a 3x improvement, Wow !
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<values.length; i++) {
values[i] = i;
}
for(int i=0; i<100; i++)
sum(values);
for(int i=0; i<100; i++)
test(values);
}
With Escape Analysis, the allocation of DoubleSlot is not done anymore.
$ /usr/jdk/jdk1.7.0b71/bin/java -server EscapeAnalysisTest
time 8889261 $ /usr/jdk/jdk1.7.0b73/bin/java -server EscapeAnalysisTest
time 1408140
I love this kind of optimisation, you don't change your program,
just use a newer VM, and got a 3x improvement :)
cheers,
Rémi
- Login or register to post comments
- Printer-friendly version
- forax's blog
- 12969 reads






Comments
JDK7 do escape analysis by
by javapete2 - 2011-01-09 13:30
I just ran the test using JDK 6u23 which I believe uses version 19 of the hotspot vm.
Firstly I ran the test without specifying any jvm options and got timings of c. 7000000
I then ran the test with -server -XX:+DoEscapeAnalysis and again for timings of 7000000
I then ran the test with -server -XX:-DoEscapeAnalysis and got timings of 22000000
this reproduces the performance improvement seen in the original post (as
you would expect since JDK6u23 uses a later vm than that used in the JDK 7
based tests of the original post).
It should also be noted that the results suggest that escape analysis is switched on by default. Moving to
JDK/JRE 6u23 for production environments from previous JDK 6 releases might be a VERY big and easy win!
In addition there are other performance options available (string operation optimizations).
www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
JDK7 do escape analysis by
by javapete2 - 2011-01-09 14:32
With this in mind I did another micro benchmark (again with JDK 6u23):
And tried
With (1) I got c. 130000000 ns, (2) I got c.80000000 ns and (3) got 130000000 ns
So the conclusion is that the option is having an effect but that it is not enabled by default .
There seems to be a 40% improvement using the option for the test case
Great but not perfect
by jaanvajakas - 2009-10-23 14: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) {int sum = 0;
int length = values.length;
for(int i=1; i<length; i++) {
int value1 = values[i-1];
int value2 = values[i];
sum += value1 + value2;
}
return sum;
}
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 EscapeAnalysisTesthad times around 49 ms,java -server -XX:+DoEscapeAnalysis EscapeAnalysisTesthad times around 6.0 ms (8 times improvement!) andjava -server NoEscapeAnalysisNeededhad times around 4.8 ms independent of the-XX:+DoEscapeAnalysisoption.I also tried 64-bit openjdk (containing OpenJDK 64-Bit Server VM 14.0-b16) on the same machine:
java -server EscapeAnalysisTestimproved to 43 ms andNoEscapeAnalysisNeededimproved to 3.4 ms butjava -server -XX:+DoEscapeAnalysis EscapeAnalysisTeststayed 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.
Great start, but
by krausest1 - 2009-10-10 03:06
I hope http://bugs.sun.com/view_bug.do?bug_id=6853701 gets fixed soon. Then my benchmark will improve too ;-)Will also become available in JDK6
by ijuma - 2009-10-06 16:02
Hi, Escape analysis and compressed references have been enabled by default in HS17 (HotSpot version) and this will eventually be available in JDK6 too (JDK6u18 early access includes HS16, so probably sometime next year). Best, Ismael... will eventually be available in JDK6 too
by stefanz - 2009-10-07 13: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.htmlYes, but not by default.
by forax - 2009-10-09 00:53
Yes, but not by default.
Does/will EA get applied by
by damonhd - 2009-10-12 00:57
Does/will EA get applied by the C1 compiler? (I've just started using the C1-only 'embedded' SE Sun HotSpot JRE!) Rgds DamonEA is not done by C1
by forax - 2009-10-12 01:52
Hi Damon,
Escape analysis is a C2 feature only.
Will it be included in C1 ? I don't know.
Rémi