Escape Analysis

The idea of implementing Escape Analysis in Mustang (J2SE 6) seems to be an impressive bet and finds a mention in this developerworks article -
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends
Escape analysis refers to the analysis done on a program to determine those dynamically allocated objects and their references that "escape" or are likely to escape the method or thread scope. This has many applications with potential implications on the program performance. The knowledge of objects being bound by the method scope opens up the possibility of allocating them in the method stack frame rather than on the heap as is typically done for any dynamically allocated objects. Dynamic memory allocation (& deallocation) comes at a price. It comes with the associated problems of fragmentation, data locality and overcoming these is costly both in terms of time and space. Talking within the Java perspective, the garbage collector takes care of reclaiming the dead object space, but even the most recent generational copying collectors can "stop-the-world" for significant amount of time. Stack allocation is not only free of these idiosyncrasies but also the deallocation happens implicitly on method return. Moreover, better data locality means that there would be less cache misses.

Knowledge of local objects also gives the compiler/optimizer a chance to get rid of the object altogether in some cases. The link above has a code snippet justifying the same.

If an object does not escape the thread, the overhead associated with its synchronization can be eliminated. This is significant because forgetting to synchronize objects being accessed by multiple threads can pose serious issues like race condition, spurious and unexpected results etc. Compilers and optimizers often reorder instructions for efficient execution. While this is acceptable in a typical sequential execution, this might cause unexpected results in a multithreaded multiprocessor environment. To add to this, the java memory model does little to ensure the data atomicity, visibility and ordering in such cases. And it is not to blame... with new environments coming up every other day, it is next to impossible to ensure correct execution. Needless to say, thread local objects are desirable and anything that can be done to identify them in a multi threaded program is worth the effort.

Okay, so escape analysis seems to be desirable. How do we go about implementing it? The short answer could be - Do it however you like! :)
Basically, what this would require is an understanding of the relationship between the various dynamically allocated objects and references... something similar to what a compiler would do in the dataflow analysis. We need to track the object right from it's inception to how it is accessed in a method to how it gets passed to other methods to whether it would be accessed by other threads until it is reclaimed by GC. There are ample articles to peruse varying in details on escape analysis in general, it's application in Java and various implementation strategies. Here's a pointer -
http://citeseer.ist.psu.edu/choi99escape.html

Whether or not escape analysis is implemented in Mustang is still being debated and you will find many forums dedicated to this topic. But then nothing stops us from delving into the code and contributing to the build!

Happy Coding :)
- Ashish.