Escape Analysis in Java 6 Update 14 - Some Informal Benchmarks
Sun recently released update 14 of the Java 6 JDK and JRE. As well as the usual collection of bug fixes, this release includes some experimental new features designed to improve the performance of the JVM (see the release notes). One of these is Escape Analysis.
To see what kind of impact escape analysis might have on my applications, I decided to try it on a couple of my more CPU-intensive Java programs. Escape analysis is turned off by default since it is still experimental. It is enabled using the following command-line option:
-XX:+DoEscapeAnalysis
Benchmark 1
The first program I tested is a statistical simulation. Basically it generates millions of random numbers (using Uncommons Maths naturally) and does a few calculations.
VM Switches: -server
95 seconds
VM Switches: -server -XX:+DoEscapeAnalysis
73 seconds
Performance improvement using Escape Analysis: 23%
Benchmark 2
The second program I tested is an implementation of non-negative matrix factorisation.
VM Switches: -server
22.6 seconds
VM Switches: -server -XX:+DoEscapeAnalysis
20.8 seconds
Performance improvement using Escape Analysis: 8%
Conclusions
These benchmarks are neither representative nor comprehensive. Nevertheless, for certain types of program the addition of escape analysis appears to be another signficant step forward in JVM performance.
From http://blog.uncommons.org/
Dan Dyer is a professional software developer in the UK. He has been programming in Java since 1997. Most recently he has been involved in the design and development of Internet casino, poker and spread betting systems. Dan's other programming interests include artificial intelligence, particularly evolutionary computation, and functional programming in Haskell. He has authored, or contributed to, a number of open source Java projects. Dan is a DZone MVB and is not an employee of DZone and has posted 11 posts at DZone. You can read more from them at their website.
- Login or register to post comments
- 5555 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Dominique De Vito replied on Tue, 2009/06/02 - 3:06am
What a news !
It's indeed quite interesting even if they are informal benchmarks. They give a taste of what is coming.
Thanks.
Dominique
http://www.jroller.com/dmdevito
Osvaldo Doederlein replied on Tue, 2009/06/02 - 7:35am
Stack Allocation is indeed a very welcome, much anticipated optimization. (Escape analysis-based lock optimizations were already implemented since first JDK6 IIRC.) I was looking to benchmark that, but you've beat me. ;-)
Just one warning: there is a bug involving escape analysis & the G1 collector; if you acivate both simultaneously, some programs will run reliably, but others will crash. I already reported this as Bug 6846464: G1: Crash within G1 collector + Escape Analysis.
P.S. Would you mind sharing the source code for these benchmarks?
Dan Dyer replied on Tue, 2009/06/02 - 8:53am
@Osvaldo, thanks for the heads-up on G1. I haven't tried that yet.
I can't provide the source for the programs. They were not specifically written as benchmarks. They were both pre-existing programs that were CPU-bound. Each is basically a loop that maxes out the CPU by doing its thing. There is little or no I/O, both programs are single-threaded and were running on an old Pentium IV running Ubuntu 9.04. I don't expect that these results will be repeatable for all programs, but they do suggest that escape analysis might deliver a noticeable improvement to some performance-sensitive code.
pimptenshi replied on Wed, 2009/06/03 - 10:20am
@Osvaldo: I think that actually stack allocation is still not implemented, 'just' scalar replacement.
Some microbenchmarks I've made seems to indicate this behaviour.
Stuart McCulloch replied on Wed, 2009/06/03 - 9:51pm
Escape analysis is really cool - the idea has actually been around for a while, IBM J9 had escape analysis in 2003:
http://www.cs.ualberta.ca/~amaral/IBM-Stoodley-talks/UofAKASWorkshop.pdf
but I'm sure the underlying theory / research goes back even further.
One side-effect of escape analysis is that local Java objects can be GC'd in the middle of a method if they're no longer used. I've seen this expose bad assumptions in internal JDK native code, such as assuming an object reference will be alive during the entire scope of a call (but this only happens if the said native code tries to sidestep JNI for performance reasons).
jiji530 replied on Tue, 2009/06/30 - 12:21am