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:
![[specjbb.png]](specjbb.png)
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:
![[volanomark.png]](volanomark.png)
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:
java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
The full java version for J2SE 5.0 is:
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Server VM (build 1.5.0_01-b08, mixed mode)
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:
![[startup.png]](startup.png)
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:
![[footprint.png]](footprint.png)
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:
![[arraycopy.jpg]](arraycopy.jpg)
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:
![[cms_server.jpg]](cms_server.jpg)
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:
![[cms_volano.jpg]](cms_volano.jpg)
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:
java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
The full java version for J2SE 5.0 is:
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Server VM (build 1.5.0-b64, mixed mode)
Please see the
VolanoMark™ 2.5 Benchmark Disclosure
Print-friendly Version
