Java 2 Platform, Standard Edition v 1.4 Performance and Scalability Guide

One of the design centers for the release of Java 2 Platform, Standard Edition (J2SE) version 1.4 was to improve the performance and scalability of the Java platform. In order to do that, the team at Sun Microsystems, Inc. put in place a rigorous program to drive these improvements, working closely with customers and partners to determine key areas where performance improvements would have the most impact. Sun Microsystems, Inc. is also driving performance improvements through the use of various industry standard and internally developed benchmarks. These improvements span areas important to both server-side and client-side Java programs.

This guide gives an overview of the performance and scalability improvements made in the J2SE version 1.4 release. This includes the results of various benchmarks to demonstrate improvements in existing APIs as well as an overview of key new technologies included in J2SE for the first time. Version 1.4 gives you the infrastructure you need in order to scale your application to:

• Utilize machines with larger numbers of CPUs
• Handle more concurrent socket connections
• Access much larger memory spaces

This guide contains sample performance results from a range of applications running on different operating systems and hardware, and helps to illustrate that the performance improvements are broadly applicable to many systems and applications.

Several key new features that improve scalability have been added to the J2SE platform in version 1.4. These include the new I/O (NIO) framework contained in the java.nio package, 64-bit support in the Solaris Operating Environment implementation of the Java HotSpot Virtual Machine, and other key enhancements.
 

New I/O

The new I/O (NIO) framework provides new features and improved performance in the areas of buffer management, scalable network I/O, and file I/O. NIO makes it possible to build servers that scale to a much larger number of connections. In previous versions of the J2SE platform, each open socket connection required management by a dedicated thread. This led to limitations in the amount of open connections a Java application could handle. J2SE version 1.4 provides the developer with the ability to have several connections per thread, which greatly increases the scalability of Java technology-based server applications. For documentation on the new Channel APIs that allow for this kind of multiplexing I/O please see:

http://java.sun.com/j2se/1.4/docs/api/java/
nio/channels/package-summary.html

A lesser-known, but still important, feature of NIO is its additions to the Java Native Interface (JNI). These new additions allow Java language and C language code to share access to certain kinds of data structures. This allows developers of applications that require access to platform native APIs to avoid the overhead of copying data across the JNI boundary.

For more information on the overhead of copying data across the JNI boundary, please see:

http://java.sun.com/docs/books/performance/
1st_edition/html/JPNativeCode.fm.html

For information on these JNI additions please see:

http://java.sun.com/j2se/1.4/docs/guide/jni/jni-14.html

For a concrete example of how these new JNI features can be used, please see:

http://java.sun.com/products/jfc/tsc/articles/jcanyon/
 

64-Bit JVM Support

Previous releases of the Java HotSpot VM were limited to addressing 4 gigabytes of memory - even on 64-bit operating systems such as Solaris Operating Environment. While 4 gigabytes seems like a lot for a desktop system, modern servers can contain far more memory. For example, Sun's new SunFire 15K server comes in a standard configuration with 288 gigabytes of memory - with a 64-bit JVM, Java applications can now utilize the full memory of such a system.

Use of the 64-bit version of the JVM isn't appropriate for all applications. However, there are several classes of applications where its use can be key: for example, applications that store very large data sets in memory. Applications can now avoid the overhead of paging data from disk, or extracting data from a RDBMS. This can lead to dramatic performance improvements in applications of this type.

Java Data Base Connectivity (JDBC) 3.0

The JDBC 3.0 specification describes a number of performance enhancements that are readily available to the developer. Primarily, enhancements to the specification allow for improved control of Connection Pooling and Statement Pooling that can be combined to offer significant performance and scalability for JDBC enabled applications. By leveraging caches of both physical database connections and statement pools, significant gains can be achieved. These optimizations particularly evident with complex statements.

The java.sql.Statement and the java.sql.ResultSet interfaces now both provide methods (setFetchDirection and setFetchSize) that permit applications to provide hints to the underlying JDBC drivers. The values supplied can be applied to each resultset produced by a statement, or to be specific, an individual result set.

In addition, the ability to establish a result set of auto-generated keys allows JDBC technology-based applications to maximize database optimizations established on previously committed data. Batch updates can also provide significant performance improvements over ordinary statement processing.

JDBC 3.0 now clearly articulates control of transaction isolation. As the transaction isolation level increases, a likely performance degradation follows as additional locks are required to protect data integrity. If the underlying data does not require such a high degree of integrity, the isolation level can be lowered improved performance.
 

There are several areas of the J2SE infrastructure that have seen substantial performance improvements over past releases. Here is a list of some of the infrastructure areas that have seen improvement in version 1.4:

• Reflective Method Invocation
• JNI Method Invocation
• Object Serialization
• Byte-code to Native-code Compilation
• Garbage Collection Policies
• Thread Management

Reflective Method Invocation

One powerful feature of the Java programming language is the ability to dynamically look up and call methods. The key constructs for doing this are contained in the java.lang.reflect package. In J2SE 1.4, the mechanism that implements these features has been reimplemented for dramatically improved performance. The chart below shows the relative performance on a simple benchmark that repeatedly calls small methods - performance is improved by a factor of 20!
 

JNI Method Invocation

In addition to the JNI features added to support the NIO framework, method calling through JNI has also improved for calling C-language methods from Java, as well as calling Java language methods from C. The results below show that the performance for calling simple native methods been improved in version 1.4 by 74% over J2SE version 1.3.1. The performance for calling Java language virtual methods from C has improved by 38%.
 

Object Serialization

The performance of object serialization has been substantially improved. Because serialization is the basis for many other Java technologies, this has an impact on several types of Java applications. In particular, object serialization is used in the implementation of technologies such as: RMI, Jini, and CORBA. Specific enhancements to object serialization in version 1.4 include:

• Faster fetching and setting field values in serializable objects
• Faster instantiation of serializable objects
• Faster invocation of custom serialization methods (e.g., class-defined writeObject, readObject methods)
• Reduced synchronization for some internal operations

Byte-code to Native-code Compilation

There have been numerous improvements made to the HotSpot Server VM's byte-code to native-code compiler. Some of the new optimizations include:

• Array bounds check elimination
• Various loop optimizations
• Improved inlining

Garbage Collection Policy

While the fundamental garbage collection (GC) algorithms used by the HotSpot virtual machine have not changed significantly since J2SE 1.3.1, there have been several subtle improvements. One of the most important is in the area of "generation sizing." J2SE version 1.4 provides improved heuristics for selecting the most efficient settings which can have dramatic effects on GC throughput.
 

Thread Management

The thread management used by the Solaris implementation of the JVM has been improved dramatically to improve scalability and end-thread starvation. In a benchmark launching worker threads equal to the number of CPUs, all the threads perform nearly equal amounts of operations (within 5%), whereas with J2SE 1.3 the spread between threads doing the most and least operations could exceed 20%. This provides improved CPU utilization on multi-CPU systems using version 1.4.
 

JFC/Swing Performance

The performance characteristics of the Java Foundation Classes (JFC) have improved substantially in this release. In particular, the Java 2D graphics system has been substantially improved in two key areas. First, the Java 2D graphics internal "pipeline" architecture has been almost totally rewritten to reduce the overhead associated with common graphics operations such as Graphics.setColor. Second, the addition of the new VolatileImage API allows developers to take advantage of hardware graphics accelerators which are common on most current PC and Workstation hardware. The result of these improvements is a significant performance boost for Swing-based GUI applets and applications.
 

Remote X

It is commonplace for users of UNIX systems run an application on one machine, but to display the GUI on another (possibly in a remote location) using the X-Windows protocol. Previous versions of the Java 2 platform were less than ideal for this environment as the Java 2D graphics system had to move large images across the network to support X-Windows. In J2SE version 1.4, Java 2D now leverages the actual X-Windows draw commands the way they were designed to be used. The chart below shows sample improvements on various Swing component tests when using Remote-X.

For more information on Java 2D performance enhancements please see:

http://java.sun.com/products/java-media/2D/perf_graphics.pdf
 

Numerous improvements in the low-level infrastructure of J2SE version 1.4 improve the results of a wide variety of server-side benchmarks.
 

Business Transactions

SPECjbb2000 (Java Business Benchmark) is the Standard Performance Evaluation Corporation's benchmark for evaluating server-side Java performance. It models a three-tier system, the most common type of server-side Java applications. SPECjbb2000 focuses on business logic, object manipulation, and the work of a middle-tier Java server workload. The benchmark represents a typical business-critical workload, including order-entry, inquiry and payment processing. The results of this benchmark show a performance improvement in J2SE version 1.4 of 58% over 1.3.1.

Key enhancements in version 1.4 that improved the SPECjbb2000 benchmark include:

• Improved GC policy
• Improved thread handling
• Improved compilation optimizations

Enterprise JavaBeans

Enterprise JavaBeans (EJB) are a key element of the J2EE platform, and J2SE version 1.4 shows a 34% improvement over 1.3.1 on a workload that uses EJBs to simulate a manufacturing and supply-chain management application.

Improvements in J2SE version 1.4 that impact this workload include:

• Improved object serialization
• Improved thread management
• Improved reflection

Java Servlets

Java Servlets are another key piece of the J2EE platform. Again, J2SE 1.4 substantially improves performance. In a benchmark that uses Java Servlets to run an online bookstore, the performance increased by 35%.

Of particular importance for this benchmark were improvements made in the Java HotSpot Server VM code optimizer.
 

Instant Messaging

The ability to manage large numbers of threads and socket connections is key to server-side applications. Enhancements to thread management, particularly on the Solaris platform, allow for better performance in these areas. On a benchmark that simulates an "Instant Messaging" server, performance has improved in version 1.4 by 73% over 1.3.1.
 

This section of the guide provides additional details of the performance numbers quoted so that you can be better informed about the meaning of these results. All performance results described in this guide used pre-release (beta or release candidate) versions of the J2SE version 1.4. The production version may produce have slight variances.

As with most performance data, the information described here is sensitive to hardware and software configuration issues. The results described in this guide are indicative of performance for certain classes of tests. Individual results may vary.

All "normalized" results are quoted as percent performance relative to J2SE 1.3.1.
 

SPECjbb2000

SPECjbb2000 is benchmark from the Standard Performance Evaluation Corporation (SPEC). Competitive claims reflect results published on www.spec.org as of 1/28/02. For the latest SPECjbb2000 results visit http://www.spec.org/osg/jbb2000.
 

Reflection Benchmark

This microbenchmark executes 3 million Method.invoke() calls of a very simple method containing a simple mathematical operation.

Solaris Configuration is using a 450 MHz UltraSPARC-II CPU
Windows Configuration is using a 366 Pentium II CPU
 

JNI Benchmark

The "J to C" portion of this microbenchmark uses Java language code to execute a minimal C language function 10 million times. The "C to J" portion of this microbenchmark executes uses C language code to call a minimal Java language virtual method call 10 million times.

Machine configuration is using a 450 MHz UltraSPARC-II CPU.
 

Swing GUI Benchmark

These benchmark results use the SwingUtilities.invokeLater() method to pump simulated events into a simple Swing GUI. A number of simulated events are pushed to each type of GUI and the amount of time to execute these events and repaint the GUI is measured.

The machine configuration is a PC running Windows NT 4.0 using a 1 GHz AMD processor and an NVIDIA GeForce 2 video card. The video is set to display in true color.
 

Remote X Benchmark

This benchmark used infrastructure similar to that described for the Swing GUI benchmark, but displayed the Swing GUI on a remote display. The hardware used was a pair of Intel Pentium-III based PC machines running Red Hat Linux 6.2 connected together over a heavily trafficked 10 megabit Ethernet network.
 

Business Transaction Benchmark

The benchmarks shown are for a 4 CPU 450 MHz UltraSPARC-II server configured with 4 gigabytes of RAM. The Java heap is limited to 2 gigabytes via command line options to the Java launcher. Full details are available at http://www.spec.org.
 

EJB Benchmark

This benchmark makes use primarily of Entity Beans. The hardware utilizes a two-tier configuration where the application server resides on an 8 CPU 400 MHz UltraSPARC-II machine, while the database resides on a 4 CPU 450 MHz UltraSPARC-II machine. The -server option was used, and some command line flags were used to configure the garbage collector. The same flags were used for the J2SE 1.3.1 and J2SE 1.4 runs.
 

Java Servlet Benchmark

This benchmark uses a set of Java Servlets that communicate with a database via JDBC. The hardware utilizes a two-tier configuration where the web server resides on an 8 CPU 400 MHz UltraSPARC-II machine, while the database resides on a 4 CPU 450 MHz UltraSPARC-II machine. The -server option was used, and some command line flags were used to configure the garbage collector. The same flags were used for both the J2SE version 1.3.1 and 1.4 runs.
 

Instant Messaging Benchmark

This benchmark simulates a server which handles routing brief text messages between a number of users. In this case there were 400 users, each of which is serviced by one worker thread. The application heap size was set to 256 megabytes and the -server option was used. The hardware configuration was a 450 MHz 4 CPU UltraSPARC-II machine.