Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up! 

News December 2005

jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

Site24x7
Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up!


jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


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.

A note from this newsletter's sponsor

Wily Technology delivers what you need: Availability, Performance and Control
The most critical web applications in the world are managed by
software from Wily, the leader in enterprise application management

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.

News

Java performance tuning related news.

A note from this newsletter's sponsor

Build performance into your Java applications with JProbe ®.
JProbe allows easy application testing without any code changes and
can pinpoint performance problems down to one line of code. Try it!

Tools

Java performance tuning related tools.

Articles

Jack Shirazi


Back to newsletter 061 contents


Last Updated: 2017-03-01
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news061.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us