State of Performance and Stability in Java 7 Update 1
On October 18th, Oracle released Java 7 Update 1, bringing Java 7 much needed stability and fixing a performance optimization issue in which the HotSpot compiler could occasionally lead to incorrect results or could even SIGSEV crashes, as we previously reported. The same issue is fixed in JDK 6 with Update 29 where it occurred only when -XX:+AggressiveOpts or -XX:+OptimizeStringConcat were used, which is not recommended for production servers.
In its Java HotSpot Virtual Machine Performance Enhancements document, Oracle describes other performance related features. The rather short document contains only one new improvement: -XX:+TieredCompilation.
Tiered compilation adds an additional step to the previous mixed mode behaviour of the compiler. Server class JVMs prior to Java 7 initially run code in interpreted mode to collect statistics. Code was then only compiled and optimized when it was hot, like having a high execution count, which gave the HotSpot VM its name. The interpreted mode however is much slower than running compiled code. -XX:+TieredCompilation allows the JVM to gather statistics for optimization whilst already running compiled code.
The relevance of this improvement is probably not very high, as startup behaviour is still not as important as in desktop/applet based applications. Although this change might reduce warmup time in highly dynamics systems, where nodes come up in quick succession.
All the other improvements listed on the page for JVM 7 were already available in Java 6:
- Compressed Oops available since Java 6 Update 14, default since Update 23 (64 bit only)
- Escape Analysis available since Java 6 Update 14, default since Update 23
- Non Uniform Memory Access Garbage Collection available since Java 6 Update 2
Compressed Oops save memory for 64 bit addresses. Instead of taking the 64 bit address from the operating system, the JVM will use a shorter address to reference the objects relative to the heap start. Most programs will significantly benefit from this feature due to reduced memory usage of object references.
Escape Analysis finds out if a newly allocated object will "escape" the current method scope. If it does not, then the object might be allocated on the method stack, and even synchronisation might be removed (lock elision). There is a comprehensive article by Heinz Kabutz on the effect of this optimization.
Non Uniform Memory Access Garbage Collection is an interesting improvement, but has been available for a long time. In modern memory architecture some areas are faster to read and write than others. Especially on multicore systems, there is memory which is reserved for the individual CPUs. Readers who are so inclined can learn more about these memory areas in an excellent article by Ulrich Drepper. The JVM will try to allocate objects in the memory used by the core where the allocating thread is executing. The performance improvement is claimed to be very high (especially on Solaris machines), but the -XX:+UseNUMA option never became default.
As most of the improvements were made available (and even default) in Java 6 Updates, there is still no compelling reason to update to Java 7 because of performance.
That is a simplistic analysis because the stability and performance of the various features are improved continuously in HotSpot. For example, Compressed Oops didn't perform particularly well in Java 6 Update 14 when compared to its performance in more recent releases. And Java 7 is not a static entity either. Java 7 update 2 (which should be out soon) will include a newer version of HotSpot with more improvements.