|
|
|
|
Back to newsletter 061 contents
Sun's engineers have put together a "Java Tuning White Paper" (see the articles referenced below and this months new performance tips). For the most part it contains good, standard tuning suggestions. But one item was new to me. Let me digress a little first, before I talk about it.
Any versioned upgrade of a production system is risky. Your tests can never provide a 100% coverage of even the functionality, let alone all the possible performance profiles. The last thing you want is for the underlying behavior of the system to change under your feet. A while back, I was upgrading one of my customer's systems from 1.4.1 to 1.4.2. During the performance test simulations of the upgrade, we found that several of the servers significantly degraded in performance, unnacceptably for a release to proceed. As I'm sure lots of you know, performance simulations of production systems take a while to run (hours) and take a while to analyze given the number of different performance statistics you need to examine. And in this case it took a significant number of tests to identify that our performance degradation was due to some subtle change in the parallel scavenge collector (-XX:UseParallelGC). In fact we had to speak to a Sun engineer before we found out that the default adaptive sizing policy had changed between those two versions of the JVM: 1.4.1 had adaptive sizing off by default (XX:-UseAdaptiveSizePolicy) whereas 1.4.2 had adaptive sizing on by default (XX:+UseAdaptiveSizePolicy).
So back to the "Java Tuning White Paper". It lists a new tuning option, -XX:+AggressiveOpts. It comes with a warning:
"The specific optimizations enabled by this option can change from release to release and even build to build. You should reevaluate the effects of this option prior to deploying a new release of Java."
There are hundreds of optional parameters to the Sun JVM, many of which alter performance in all sorts of ways. Most are for Sun's internal diagnostic use. Occasionally some are useful enough that Sun makes them more or less "standard", that is Sun actually recommends you try them because they are more or less stabilised. Here, Sun is suggesting you try an option that is not only experimental, but is actually intended to stay permanently experimental! Anyone foolish enough to put this flag in production has only themselves to blame if an upgrade produces a degradation in performance - and Sun are even kind enough to tell you so in their tuning guide.
The first best practice listed in the white paper is "Use the most recent Java release". Put that together with the suggestion to try the -XX:+AggressiveOpts and you have a recipe for a heck of a lot of performance testing or, alternatively, some upgrades will inevitably follow my adaptive sizing experience with time and money spent wastefully trying to track down performance degradations due changes in default JVM behavior.
While it is very nice of Sun to want to increase the number of Java customers who need the services of performance specialists like me, personally I will be recommending the opposite: Do not try -XX:+AggressiveOpts because in the worst case where it actually produces a performance improvement and you put it in production, the cost of supporting it will be significantly more than gaining that same performance improvement in some other way.
Read on for our usual list of what's new in Java performance articles, news, tools and more. And, of course, don't miss our many new performance tips extracted in concise form.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 061 contents
