Linked by Eugenia Loli-Queru on Tue 11th Oct 2005 00:14 UTC, submitted by Frank Schoep
Thread beginning with comment 43061
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.




Member since:
Yes, it will be in unless Sun runs into some major problems.
Notice that even though escape analysis is already implemented in Mustang, right now (b55) the optimizations that need information from escape analysis are not yet implemented; the most important are lock elimination and stack allocation. You can check the working of escape analysis with -XX:+PrintEscapeAnalysis -XX:+DoEscapeAnalysis (I think the "print" option is exclusive to the fastdebug build). If you can read Assembly, check also -XX:+PrintOptoAssembly (this is not final ASM code but it's very close), also in fastdebug builds. Pretty hot tool to study any microbenchmark ;-)
The small difference of performance that you may see in current builds, turning escape analysis on, should be due to minor effects of this analysis in lesser optimizations that already explore it. But the big bucks have yet to come. Stack allocation not only saves GC overhead, but it also opens the door to other opportunistic optimizations, by inlining object fields as local variables (which allows register allocation of the hottest fields), and simplifying (inlined) method invocations that depend only on some fields of the inlined objects. Think for instance in Iterator objects, which are ubiquitous in modern Java code, never escape methods, and are very small (typically 2-3 fields). Escape analysis + stack allocation + field inlining and other optimizations, can produce code that's as fast as iterator-less code(*), e.g. a "for (int...)" to iterate an ArrayList.