|
|
|
|
Back to newsletter 117 contents
Until now, if you wanted to eliminate all but the tiniest GC pauses (e.g. everything over 1 millisecond), you had to either program in a very non-object oriented way (almost eliminating object creation and destruction); or program in a specialized way to the Java Realtime System, or sometimes you would be lucky and the (Oracle) JRockit Real Time or IBM WebSphere Real-time would work well on your app and keep the GC pauses right down there.
But now Azul are providing a mainstream option that specifically targets keeping GC pauses tiny for the majority of Java applications, giving us all a new option with their new Zing product and the Managed Runtime Initiative. This is great news since with Oracle owning both JRockit and HotSpot, competitive pressures on JVM evolution were hugely reduced. And what competition Azul are providing: with GC pauses typically under 1 millisecond even for 100GBs heaps, and even the occasional longer GC pause still only into the 10-20 millisecond range! (Gil Tene, Azul's CTO, says as far as they can tell these longer GC pauses are caused by the OS context switching during a GC pause, and not because the GC pause actually takes any longer).
Previously, Azul was a very niche competitor - you had to buy their hardware if you wanted their low pause Java runtime, and typically that was only going to fly if you needed very large scaled JVMs. For the smaller low latency application that desperately wanted low pause GCs, Azul didn't even feature on the evaluation list. But now Azul has ported their runtime to run on Intel and AMD processors, suddenly this is an option for many more applications. And Azul haven't stopped there, they've also created the Managed Runtime Initiative (MRI) to provide a free JVM option with those incredibly low GC pauses. To enable this, they've contributed kernel changes to linux and implemented a Java Runtime based on openjdk - it's all available from the MRI site; and although currently it's only an alpha release, Azul are intending to stabilize the combination to a fully supported release.
This is not only serious new competition for Oracle's JVM, but realistically targets two of the four top JVM performance challenges (GC pause times and very large heaps; the other two are higher visibility into production runtimes; and transparently utilising multiple cores). Java long ago reached production maturity capable of handling almost anything thrown at it but, every time I think Java might be slowing down, yet another brilliant change happens in the Java space to make it yet better again. Amazing that after 15 years on the leading edge, it just carries on staying right there.
Now on with this month's newsletter. We have all our usual Java performance tools, news, and article links. Javva The Hutt is back telling us about the $300 line of code. Over at fasterj we have a new cartoon showing the IllegalAccessException; and, as usual, we have extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 117 contents
