Escape analysis is a form of static analysis in which the compiler determines if a new object reference (or pointer if you’re not talking about Java) can possibly be visible outside the current thread or beyond the current scope block. If it cannot be, the object can be safely allocated on the stack instead of the heap. This is potentially a very significant optimization, since it eliminates both the overhead of later garbage collecting the object and the heap fragmentation that may occur from the allocation and deallocation of many small objects.
Java 6 (“Mustang”) was originally slated to include escape analysis in the javac Java compiler. But if I am reading the release notes correctly, this optimization has been delayed at least until Java 7 (“Dolphin”) or maybe later. Java 7 may be released sometime in 2008.
I’m bummed. Escape analysis has been talked about at least since around 1999. I was all hot for escape analysis as one more reason why Java could be the next big embedded programming language. Obviously Java has made in-roads in the embedded world, becoming pretty standard in a lot of handheld consumer devices. I helped develop an embedded telecommunications product in Java as early as 1999. But escape analysis would have eliminated one of the concerns many embedded developers have rightly had regarding Java on hard real-time or tightly memory constrained platforms.
On the plus side, I’ve had zero problems porting the tiny little Buckaroo Java code base to Java 6, either using the Sun javac with Ant, or the Eclipse 3.2 incremental compiler.
My jonesing for escape analysis in Java remains unrequited.
J. Choi et al., “Escape analysis for Java”, Proc. 14th SIGPLAN OOPSLA, 1999
M. Love, “Optimized Java: Escape Analysis”, Dr. Dobb’s Portal, 2006-06-01
Sun Developer Network, Java SE 6 Release Notes: Features and Enhancements
Sun Developer Network, “Eliminate locking of unescaped objects”, Bug ID 6339956, 2005-10-21
Buckaroo, Digital Aggregates Corp., 2007