Escape Analysis in Mustang - I

EDIT: As commented by Brian, these Escape Analysis optimizations were dropped before final release and deferred to Java 7. The debug version of VM can no longer be found at http://download.java.net/download/jdk6/6u1/promoted/b03/binaries/jdk-6u1-ea-bin-b03-windows-i586-debug-19_jan_2007.jar. Production VM here means production release type, as compared to debug, not the final release.

Java 6 brings a lot of improvements in (much ignored) synchronization; like lock elision, adaptive locking etc., under, the awaited, escape analysis hood. I've been reading quite a bit on stack allocation and lock detection techniques to reduce GC overhead. (as stack comes for free; and sometimes, on full speed core).

Escape analysis is one of the interesting techniques in compiler optimization, read more here.

Few days back, I posted an off-topic curiosity on lang.java google group, It's not officially mentioned anywhere that escape analysis is implemented in mustang releases. Brian Goetz wrote an article stating EA is available in mustang builds, that article is pretty old and someone questioned whether it's really available or not...

A web search revealed that escape analysis *is* available in mustang (not well marketed?), and production VM binary (I've b-03) supports it out of the box in server mode; debug binaries supports few more switches to see the analysis. I'm trying to benchmark it with few programs playing around large number of object creation, not a big deal.

Well, if you are interested, try these switches with mustang (in server mode)
-XX:+PrintEscapeAnalysis,
-XX:+PrintOptoAssembly,
-XX:+DoEscapeAnalysis (works on production VM only).

May be this weekend, I'll post the results of the benchmarks and other findings on it.
Java's performance is getting better and better..

Importance of System Metaphor

Kent Beck describes System metaphor in his legendary book Extreme Programming : Embrace Change as A Story that everyone in XP team can tell about how the system works.

So? Why do we need one more buzzword? Why should I care about it?

Consider a team working on a large software application; typically work is componentized by the architects and/or managers. Every member works on specific part of the component or on specific component. Few people (Software Heroes) know what is the real picture of the application and how it works or is supposed to work. (As a metaphor, every member in group is holding/attached to parts of an elephant, some one is holding his pillar leg, some one holding tail and few holding trunk and god-sized ear; while no one knows how he looks like and how to sell it! Nawal, thanks!).

The result? Software heroes become the concentration point (High risk :)); lack of shared vision in team leads to communication gaps (Our product can generate application, end-to-end in three different platforms); Everyone in the team has her own (mis)understanding of the application (we're building a modeling tool, no- it's a part of framework; ok, that framework is persistence framework- may be that framework is generated using our tool); frequent suboptimal technical decisions (e.g. selection of specific framework which may not fit well with other's work- we'll code GEF editor, we will generate GEF Editor using GMF); rework/duplication (existence of several similar utilities in different module);

Having worked in such scenario, I realized that lacking shared vision or system metaphor results in chaos (implementation to deployment), countless bad decisions and loss of interest in regular work. Everyone becomes concerned about his/her own work rather then end-product (customer satisfaction) - there is no more a collective ownership. Work becomes chore and no fun :(. We may even lose out good ideas from team which might be real worth. Team becomes just a mixture of testers, coders, analyst and so on(and you'll not mind being called a Java Resource!).

One more thing I love about XP is, it keeps everyone informed of what is going on, which in turns backs feedback cycles. When everyone knows what is going on, they participate in overall effort rather then mere work assignment.

I understood the importance of system metaphor the harder way..

Refactoring and Upfront Designs

Low level software design is one of my regular work, most of the time it turns out to be really interesting; so much so that I fail to sense environmental changes around me :). Most of the decisions in such designs, confined to refactoring, are upfront.

There were times when these decisions used to drive me nuts (for example, I used to extend framework at larger granularity, failed to identify framework extensions at right places etc.), with time (and few refactoring book skims) I learned how to simplify it. Some of them are separating the concerns of mammoth classes into few "aware" type of interfaces (Spring style), distribute methods, extract stateless routines, derive common abstract base class etc. These decisions are quite easy to tackle with upfront designs.

Refactoring is wonderful, refactoring to patterns is even more interesting. Recently, Ketan identified design smells in his GUI testing framework for SWT. I did a test drive into the initial framework to understand and tried the same upfront approach to make it smell free, I failed; but I understood the potential pain points. Then, We brainstormed and discussed the design on white board, espied the smells; asking questions, suggesting and rejecting alternatives designs. That cleared few confusing points and we came with a good enough, smell free design (Ketan, all we did was shifting and distributing the bottleneck somewhere else :), as it can't be eliminated - "SWT"- I wonder why SWT is not very cleanly designed, performance?).

The lessons learned? You can't refactor well if you're in confusion (requirements or other), refactoring in this case drags you away, and Upfront designs takes extensive experience on variety of problem domains.

The Pune Eclipse Developer Group

Sriram and Ketan initiated The Pune Eclipse Developers' group to promote collaboration between eclipse developers in Pune. I came to know about good strength working on eclipse plug-ins and related technologies in Pune, its good idea to get them together, share ideas-techniques and socialize with like minded people around town.

Recently at GNUnify '07 Ketan and Sriram spoke about Eclipse Rich Client Application Development. Eclipse Enthusiast can find the presentation here and workshop code here. The presentation is interesting, explains Eclipse architecture; frameworks around it; benefits etc.

I wish Pune Eclipse Developers' group existed before few months, I would have found few more good guys for my team :).