Dan is the founder of Rectangular Software, an independent UK software company that provides development services and builds its own mobile and web applications. Dan has over a decade of experience in the software industry, building a wide variety of systems including casino, poker and spread-betting platforms, mobile applications, e-commerce websites, and network security software. His 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 has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Escape Analysis in Java 6 Update 14 - Some Informal Benchmarks

  • submit to reddit

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:


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%


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/

Published at DZone with permission of its author, Dan Dyer.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


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.




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.


cleber muramoto 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:


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 (not verified) replied on Tue, 2009/06/30 - 12:21am

thanks for your post.perhaps you will like abercrombie ed hardy mortgage rates tiffanys ed hardy Is not it?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.