One of the reasons I like Java is that the virtual machine allows you to forget about the underlying hardware/OS most of the time and focus on solving your business problems. And I have almost become complacement about a steady release of new versions of Java, generally faster, with new features and fewer bugs – and all for free!
Last week, however, we had a reminder that this does not always work according to plan. A customer updgraded their boxes from Java 1.5 to Java 1.6 and performance collapsed. Not just a little bit, but by a huge margin. We ran their tests on our Windows box and they were absolutely right – what took 1 second on Java 1.5 was now taking 17 seconds. It was the same code, same input PDF, same hardware – all that was changed was the JVM.
Intrigued, we ran the tests under a profiler and traced the issue to a single cause – the PDF we were handling was accessing the CMM colour function to handle an ICCColorspace. It appears that Sun has altered the underlying library used the JVM to handle this and for our usage, it has much poorer performance.
Happily, we were able to rewrite the code to avoid this (so our test now takes less than a second on both Java 1.5 and Java 1.6). But the reminder for us, is that while Java may offer a virtual machine, its performance can still vary widely between versions. So it still makes sense to optimise even a virtual language towards a specific target platform and version if performance is important.
Latest posts by Mark Stephens (see all)
- My 5 key takeaways from JavaOne 2017 - October 6, 2017
- My notes and pictures from thursday JavaOne 2017 - October 5, 2017
- My notes and pictures from Wednesday JavaOne 2017 - October 5, 2017
- My notes and pictures from Tuesday JavaOne 2017 - October 4, 2017
- My notes and pictures from Monday at JavaOne 2017 - October 3, 2017