But I digress... Rick Palkovic's blog

Like any big trade show, JavaOne is crowded and noisy. Kind of like a busy airport, except people mostly walk in circles. And they've left all their kids at home.

All those crowds can make things a little confusing, and I'm here to tell you that it's possible for JavaOne attendees to get lost -- even brilliant ones such as myself.

For one thing, I can't find the first technical session I'd scheduled. Somehow it had been moved to Tuesday, and, since it's Thursday already, it looks like I won't be in attendance. Suddenly my choices seem to be a session describing peer-to-peer communication in the battlefield of the future or a discussion of the HotSpot optimizer for the Java SE 6 Virtual Machine (code name Mustang). Being a war-weary civilian still trying to forget his sojourn in the military-industrial complex, I opt for compiler optimization.

TS-3422 New Compiler Optimizations in the Java HotSpot (TM)) Virtual Machine
Presenters: Stephen Dever, Steve Goldman, and Kenneth Russell

As an Otmar Liebert tune flows out over the PA system to soothe me, I find myself wondering just why a developer would want to know how his compiler optimizes code. This session really has nothing to do with my area of expertise or my job assignment. Writing a good compiler is somebody else's job, right? I just run the compiler -- hey, I'm trying to write an application here! Still, I suppose it doesn't hurt to know these things. As a minimum, it might help when setting compiler flags if something goes wrong that can't be explained in any other way.

When Ken starts his presentation, my inner nerd awakens and I become interested in spite of myself. The HotSpot VM has roots in Smalltalk and Self. The goal of the project is aggressive optimization and dynamic deoptimization, the focus is on new optimizations and lightweight locking.

For one thing, the HotSpot optimizer tries to address the issue of a single thread locking a Java object repeatedly, which turns out to be the common case. Letting a thread lock an object, release it, and immediately relock it again and again is a waste of cycles -- why not introduce a bias that keeps the object locked a bit longer, eliminating the need to relock? Sounds good. But, what if keeping the object locked unnecessarily keeps other threads from accessing it? Like other attempts at sophisticated optimizations, things can get very complicated quickly. HotSpot designers have given Some thought to developing a lock bias algorithm that favors an object's being locked a bit longer by a single thread while avoiding penalizing other threads that also want access to the object.

Steven Dever now describes Escape Analysis, which tries to figure out how to allow different threads to make arbitrary changes to an object without creating chaos. Solutions include eliminating the locking of objects altogether, optimizing field references, and allocating objects on the stack frame instead of the heap. Steven finishes the discussion and I'm left with the barest inkling of how these solutions might work (barriers to understanding, I must add, are entirely my own).

Now it's Steve Goldman's turn. In ten minutes, he tries to make us understand Tiered Compilation and other optimizations. Tiered compilation results from the recognition that most client-resident compilers run fast, but produce code that runs slowly. On the other hand, most server-resident compilers run slowly because they perform a lot of optimization, but produce code that runs quickly.

Tiered compilation means you compile the parts of your application that benefit from optimization on the server-based compiler, and quickly compile parts that don't need to be optimized on the client-based compiler. Easy to say, but hard to do -- mostly because the result of one compiler can't call methods produced by the other one.

When the session is over, I come away with the feeling -- freely acknowledged by the presenters -- that HotSpot is a work in progress. Those who labor in the dusty basement workshops of compiler optimization deserve our thanks. Join the forum at https://mustang.dev.java.net/ to offer your own views.