1   Introduction
2   New Features and Performance Enhancements
3   New Platform Support
4   Going Further

While J2SE 5.0 has added many new features Sun Microsystems has also been working to continue to improve scalability and performance, with a new emphasis on startup time and memory footprint.

This guide gives an overview of the performance and scalability improvements made in the J2SE 5.0 release along with various benchmarks to demonstrate the impact of these improvements.

J2SE 5.0 includes a number of new features and enhancements to improve performance in many areas of the platform. Improvements to new language features include: additions to the virtual machine, enhancements to the base and integration libraries, the user interface, deployment, tools and architectures, and OS & hardware platforms. Enhancements to program execution speed include: Garbage collection ergonomics, StringBuilder class, Java 2D technology enhancements, and performance and memory usage improvements to image I/O.

2.1   Ergonomics in the 5.0 Java Virtual Machine

Getting the best performance out of the JVM has often required detailed hand tuning of command line options. Yet many users never set command line options for performance. In order to give the best possible performance in a variety of situations Sun Microsystems has improved the performance of the JVM even when no command line options are used.

In J2SE 5.0 the default selection for the garbage collector, heap size, and runtime compiler are now chosen automatically. These new selections better match the needs of different types of applications while requiring less command line tuning.

In addition a different way of tuning the heap has been added for the throughput garbage collector. This new tuning allows the user to specify performance and memory utilization criteria to dynamically tune the sizes of the heap. This "self tuning" behavior is referred to in this document as "ergonomics".   For more on ergonomics please see the Ergonomics in the 5.0 Java Virtual Machine document.

The performance improvements from ergonomics are significant.  Here we compare SPECjbb2000 performance between J2SE 1.4.2 and J2SE 5.0. This test was conducted on a Sun Fire V40z with 4 x 2.4 GHz AMD Opteron CPU's and 8 GB RAM running Solaris 10:

In each case we ran the benchmark without any performance arguments (except that -Xmx512m was required for proper benchmark execution with J2SE 1.4.2).
Please see the SPECjbb 2000 Benchmark Disclosure

We also compared VolanoMark™ 2.5 performance between J2SE 1.4.2 and J2SE 5.0. This test was conducted on
a Sun Fire V40z with 4 x 2.4 GHz AMD Opteron CPU's and 8 GB RAM running Solaris 10:

In each case we ran the benchmark in loopback mode without any performance arguments. The result shown is based upon relative throughput (messages per second with 400 loopback connections)

The full java version for J2SE 1.4.2 is:

The full java version for J2SE 5.0 is:

Please see the VolanoMark™ 2.5 Benchmark Disclosure

2.2   High Precision Timing

The method System.nanoTime() has been added, providing access to a nanosecond-granularity time source for relative time measurements. The actual precision of the time values returned by System.nanoTime() is platform-dependent.

2.3   StringBuilder Class

This class provides an API compatible with StringBuffer, but with no guarantee of synchronization. This class is designed for use as a drop-in replacement for StringBuffer in places where the string buffer was being used by a single thread (as is generally the case). Where possible, it is recommended that this class be used in preference to StringBuffer as it will be faster under most implementations. See the API documentation on StringBuilder for more information.

2.4   Java 2D Technology Improvements

Added 2D features include expanded Linux and Solaris printer support, new methods for creating fonts from files and streams, and new methods related to VolatileImages and hardware acceleration of images. A number of internal changes to text rendering code greatly improve its robustness, performance, and scalability. Other performance work includes hardware-accelerated rendering using OpenGL (disabled by default). See the Java 2D documentation for more information.

2.5   Image I/O Improvements

J2SE 5.0 improves image processing performance and adds readers and writers for new file formats to the Image I/O system. For more information see the Image I/O documentation.

2.6   Thread Priority on the Solaris Platform

JRE 5.0 updates the priority mapping such that Java threads at NORM_PRIORITY can now compete as expected with native threads. An excellent reference for these topics is Chapter 9, "Threads," in Joshua Bloch's book Effective Java Programming Language Guide . See also the Thread Priority on the Solaris Platform document.

2.7   Class Data Sharing

The class data sharing feature is aimed at reducing application startup time and footprint. The installation process loads a set of classes from the system jar file into a private, internal representation, then dumps that representation to a "shared archive" file. During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes. For more information see the Class Data Sharing documentation.

Java Virtual Machine performance improvements in J2SE 5.0, including Class Data Sharing, have contributed to improved startup and footprint performance. Here we compare startup performance between J2SE 1.4.2 and J2SE 5.0. This test was conducted on a Pentium 4 2.8 GHz system with 1 GB memory. The benchmark measures the time necessary to initialize the NetBeans IDE version 3.5.1:

The startup comparison above shows relative performance (bigger is better): for Windows XP J2SE 5.0 starts 8% faster,
and on the Sun Java Desktop System J2SE 5.0 starts 22% faster than J2SE 1.4.2, respectively.

Below we compare memory footprint required between J2SE 1.4.2 and J2SE 5.0 for starting up a rich client Swing-based application:

The footprint comparison above shows relative performance (smaller is better). Measuring the real memory impact of a Java application is often quite difficult. Perhaps the first hurdle in understanding footprint is that conventional system utilities, such as Task Manager on Windows, only tell part of the footprint story. Memory reported depends on whether application data and programs are read as conventional files or memory mapped files. In other words often the true memory footprint of an application includes all the files that have been brought into the operating system's file system memory cache... Often memory pages that are shared by other processes or in the file system cache are not reported by conventional tools. Getting consistent footprint measurements is further complicated by accurately measuring the same moment in an application's lifetime. Clearly the longer an application operates the more likely it is to perform classloading, compilation or other activities that affect footprint. The fantastic news for users of J2SE 5.0 is that despite adding massive new functionality Java Engineering has actually pared down core JVM memory usage and leveraged Class Data Sharing to make the actual memory impact on your system lower than with J2SE 1.4.2!

The systems used for this benchmark included:

• Windows XP Professional, Version 2002, Service Pack 1
  running on a 930 Mhz Pentium III system with 384MB of RAM
• Red Hat Linux 3.0 Advanced Server
  running on a 1.4 GHz system with 512 MB of RAM
• Solaris 9 running on a SunBlade 2000, 900 Mhz UltraSPARC IV machine with 1GB of RAM

2.8   Monitoring and Management for the Java Platform

This release of J2SE offers significant enhancements for monitoring and management for the Java platform using JMX and SNMP. Please see the Monitoring and Management for the Java Platform document for details.

2.9   Optimizations for x86 / x64

Many changes were made in J2SE 5.0 to take advantage of the performance features in modern x86 and x64 CPUs. A good example of this are the optimizations made to System.arraycopy() . In J2SE 1.4.2 System.arraycopy() was implemented using memmove() which performed well on Solaris, but was found to be a performance bottleneck on Linux. In J2SE 5.0, calls to memmove() were replaced with highly optimized x86 and x64 instructions tailored for running Java on these modern processors.

Here we compare array copy performance between J2SE 1.4.2 and J2SE 5.0. This test was conducted on
a Sun Fire V40z with 4 x 2.4 GHz AMD Opteron CPU's and 8 GB RAM running Solaris 10:

The benchmark shown above involves copying large amounts of data in several threads, with heavy use of System.arraycopy(). The test was conducted using highly tuned parameters for J2SE 1.4.2 and the exact same parameters for J2SE 5.0 as to eliminate any advantage J2SE 5.0 would gain from ergonomics. Here we are highlighting the array copy optimization on x86 platforms while holding the hardware constant.

2.10   HotSpot™ Reliability

The Java™ HotSpot™ virtual machine for J2SE 5.0 benefits from improved reliability. But how is reliability related to performance, you ask?
Because the performance of a JVM that's down is zero!

During the development cycle for J2SE 5.0 a series of release controls were put in place that have resulted in much better product reliability.
The J2SE 5.0 release of the HotSpot™ virtual machine includes 8000 bug fixes.

2.11   Concurrent Low Pause Garbage Collector Improvements

As mentioned above Java™ HotSpot™ Ergonomics includes the choice of the garbage collection algorithm. In certain situations described in the Tuning Garbage Collection with the 5.0 Java Virtual Machine document concurrent low pause collector may be a better choice for the application at hand.

The Concurrent Low Pause Garbage Collector, also known as CMS, has had several improvements for J2SE 5.0. Garbage collection pauses are shorter because of better use of parallelism during collection periods during which application threads are stopped. The pauses are also more uniform due to deliberately spacing pauses such that there is less impact on collection latency as seen by application threads. And the heap is better utilized due to improved promotion failure handling which postpones the need to start collections.

These improvements explain the dramatic performance gains in this CMS Server Benchmark (a multi-threaded, memory intensive application). This test was conducted on dual CPU Xeon 3 GHz systems with 4 GB of memory:

J2SE 5.0 ergonomics also includes better handling of thread local allocation buffers (TLABs). Adaptive resizing of TLABs reduces young generation fragmentation and wasted space thus reducing the number of collections. While these TLAB improvements are not specific to CMS we see here that they produce a dramatic improvement in the thread intensive VolanoMark™ benchmark:

The result above was conducted on a 4 CPU Ultra 80 running Solaris 9 and comparing throughput with 400 loopback connections. In each CMS result above we ran the benchmarks the following options:

• -server
• -Xmx512m
• -XX:+UseConcMarkSweepGC

The full java version for J2SE 1.4.2 is:

The full java version for J2SE 5.0 is:

Please see the VolanoMark™ 2.5 Benchmark Disclosure

The cross-platform capabilities of Java have expanded in J2SE to cover additional hardware and software platforms.

Please see the Supported System Configurations chart for full details.

3.1   Hardware

As a result of the Sun-AMD Alliance J2SE hardware platform coverage has expanded to include performance enhancements for AMD Opteron.

3.2   Operating Environments

4.1   Java Performance Portal

For the latest in Java Performance best practices, documentation, tools, FAQs, code samples, White Papers and other Java performance news check out
the Java Performance Portal.

Three especially relevant performance links for J2SE 5.0 are given here:

4.2   J2SE 5.0 Documentation

Be sure to check out the wealth of J2SE 5.0 Documentation including the
New Features and Enhancements and the
J2SE 5.0 Overview.

4.3   Performance Articles

4.4   Benchmark Disclosure