Back to newsletter 066 contents
As usual, my attendence at JavaOne was virtual. One of these days I'll retire, and then I'll have the time to go. On my current schedule it will be JavaOne 2035.
Despite that I had the delightful pleasure of attending a presentation by Greg Bollella on real-time Java (he led the Real-Time for Java expert group under the JCP). As part of his presentation he showed highights from his JavaOne presentation in the closing keynote. Very entertaining, and I got to see what people had been going on about with the slot car races.
But significantly more impressive for me was the animation which continued without pauses even while other threads were grinding to a halt from a huge volume of garbage being created, and having that garbage collected. Deterministic control over critical application thread processing without having to worry about interfering effects from other non-critical threads or garbage collection. This is significant stuff.
Real-time Java has overhead. You are trading throughput for that tight deterministic control. 15% reduced throughput if you take an existing Java app and run it on the RTSJ JVM. And throughput handling, expecially at peak flow, is critical for the enterprise systems I typically deal with. So my inital thought was that real-time would have limited applicability in the domains I tend to work in. But Greg's comment that currently many Java systems are run at low utilization in order to have spare capacity available for handling peaks, whereas with real-time the utilization could be increased significantly because peaks can be handled deterministically, hits the enterprise space dead centre. I'm sold.
One thing I thought curious was that the games developers have been crying out for this type of capability in Java for years, but now that its here Sun seem to have no plans to port the RTSJ JVM to the desktop. As these games are often deployed with a JVM, this seems to me like a reasonable target to go for. Check out the potential market Sun, I'd say that's an opportunity worth evaluating.
This month's selected articles include some of the most fascinating I've seen in quite a while. Richard Friedman shows why parallelizing an application is much less important than optimizing it; Ethan Nicholas gives a crystal clear explanation of Reference types; Don't miss Brian Goetz's masterclass on nonblocking algorithms; and definitely read the interview of Scott Oaks on profiling, which gives us our first extracted quote of 2006:
"You always hope that you'll load an application into a profiler, it will show that there's a hotspot in the code accounting for 60% of the time, and you can just go fix that and call it a day ... But in reality, bottlenecks are subtle. Leaf methods in a profile will all show very little CPU usage; root methods will all be too far removed from the source of the bottleneck. So you're left to walk up and down the stack and figure out where to look. I'm often asked how to do this well, and it's not really something I can explain. I think with practice you just develop an intuition for it."
Or, of course, we can train you to develop the skill. Now read on for our news, links to those selected articles, Kirk's roundup of discussions and his Sun Tech days presentation in South Africa; also we bring you a tool report this month on Compuware's Vantage Analyzer and, of course, we have our many new extracted performance tips.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 066 contents