Java VM Tuning

1.      Introduction

This Java Virtual Machine document is intended as a reference for Java Performance Tuning information, techniques and pointers.

1.1.    Goals

The goals of this document is to collect the best practices and "How To" for Java Performance in one place.

The initial target for this tuning document is tuning server applications on large, multi-processor servers. Future versions of this document will explore similar recommendations for desktop Java performance.

2.      Categories of Java HotSpot VM Options

Standard options recognized by the Java HotSpot VM are described on the Java Application Launcher reference pages for Windows, Solaris and Linux. This document deals exclusively with non-standard options recognized by the Java HotSpot VM:

·         Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.

·         Options that are specified with -XX are not stable and are not recommended for casual use. These options are subject to change without notice

3.      Tuning Techniques

3.1.    Ergonomics Settings

Before starting to tune the command line arguments for Java be aware that Sun's HotSpot™ Java Virtual Machine has incorporated technology to begin to tune itself. This smart tuning is referred to as Ergonomics. Most computers that have at least 2 CPU's and at least 2 GB of physical memory are considered a server-class machine which means that by default the settings are:

·         The -server compiler

·         The -XX:+UseParallelGC parallel (throughput) garbage collector

·         The -Xms initial heap size is 1/64th of the machine's physical memory

·         The -Xmx maximum heap size is 1/4th of the machine's physical memory (up to 1 GB max).

Please note that 32-bit Windows systems all use the -client compiler by default and 64-bit Windows systems which meet the criteria above will be treated as server-class machines

3.2.    Heap Sizing

Ergonomics significantly improves the "out of the box" experience for many applications, but optimal tuning often requires more attention to the sizing of the Java memory regions.

The maximum heap size of a Java application is limited by three factors: the process data model (32-bit or 64-bit) and the associated operating system limitations, the amount of virtual memory available on the system, and the amount of physical memory available on the system. The size of the Java heap for a particular application can never exceed or even reach the maximum virtual address space of the process data model.

For 32-bit, the maximum is 4GB and for 64-bit it is unlimited.

For a single Java application on a dedicated system, the size of the Java heap should never be set to the amount of physical RAM on the system, as additional RAM is needed for the operating system, other system processes, and even for other JVM operations.

On systems with multiple Java processes, or multiple processes in general, the sum of the Java heaps for those processes should also not exceed the size of the physical RAM in the system

The next most important Java memory tunable is the size of if the young generation (also known as the NewSize). Generally speaking the largest recommended value for the young generation is 3/8 of the maximum heap size.

3.3.    Garbage Collector Policy

The Java™ Platform offers a choice of Garbage Collection algorithms. For each of these algorithms there are various policy tunables. Instead of repeating the details of the Tuning Garbage Collection document here suffice it to say that first two choices are most common for large server applications:

·         The -XX:+UseParallelGC parallel (throughput) garbage collector, or

·         The -XX:+UseConcMarkSweepGC concurrent (low pause time) garbage collector (also known as CMS)

·         The -XX:+UseSerialGC serial garbage collector (for smaller applications and systems

3.4.    Other Tuning Parameters

By appropriately configuring the operating system and then using the command line options -XX:+UseLargePages (on by default for Solaris) and -XX:LargePageSizeInBytes can get the best efficiency out of the memory management system of the server. Note that with larger page sizes we can make better use of virtual memory hardware resources (TLBs), but that may cause larger space sizes for the Permanent Generation and the Code Cache, which in turn can force to reduce the size of Java heap. This is a small concern with 2 MB or 4 MB page sizes but a more interesting concern with 256 MB page sizes.

An example of a Solaris-specific tunable is selecting the libumem alternative heap allocator. To experiment with libumem on Solaris ,use the following LD_PRELOAD environment variable directive:

·         To set libumem for all child processes of a given shell, set and export the environment variable
LD_PRELOAD=/usr/lib/libumem.so

·         To launch a Java application with libumem from sh:
LD_PRELOAD=/usr/lib/libumem.so java java-settings application-args

·         To launch a Java application with libumem from csh:
env LD_PRELOAD=/usr/lib/libumem.so java java-settings application-args

Default values are listed for Java SE 6 for Solaris Sparc with -server. Some options may vary per architecture/OS/JVM version. Platforms with a differing default value are listed in the description.

·         Boolean options are turned on with -XX:+<option> and turned off with -XX:-<option>.

·         Numeric options are set with -XX:<option>=<number>. Numbers can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and 'g' or 'G' for gigabytes (for example, 32k is the same as 32768).

·         String options are set with -XX:<option>=<string>, are usually used to specify a file, a path, or a list of commands

Flags marked as manageable are dynamically writeable through the JDK management interface (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. In Monitoring and Managing Java SE 6 Platform Applications, Figure 3 shows an example. The manageable flags can also be set through jinfo -flag.

The options below are loosely grouped into three categories.

·         Behavioral options change the basic behavior of the VM.

·         Performance tuning options are knobs which can be used to tune VM performance.

Debugging options generally enable tracing, printing, or output of VM information

3.4.1.        Behavioral Options

 

3.4.2.        Performance Options

3.4.3.        Debugging Options

4.      Monitoring and Profiling

4.1.    Monitoring

The Java™ Platform comes with a great deal of monitoring facilities built-in. Please see the document Monitoring and Management for the Java™ Platform for more information.

The most popular of these "built-in" tools are JConsole and the jvmstat technologies.J2SE 5.0 includes the following APIs for monitoring and management:

4.1.1.1.  Java Virtual Machine Monitoring and Management API

The java.lang.management API enables monitoring and managing the Java virtual machine and the underlying operating system.  The API enables applications to monitor themselves and enables JMX-compliant tools to monitor and manage a virtual machine locally and remotely.

Example code is provided in the JDK_HOME/demo/management directory.

4.1.1.2.  Sun Management Platform Extension

The com.sun.management package contains Sun Microsystems' platform extension to the java.lang.management API and the management interface for some other components of the platform.

4.1.1.3.  Logging Monitoring and Management Interface

The java.util.logging.LoggingMXBean interface enables to retrieve and set logging information.

4.1.1.4.  Java Management Extensions (JMX)

The JMX APIs define the architecture, design patterns, interfaces, and services for application and network management and monitoring in Java.  The APIs are based on the JMX specification

4.2.    Profiling

The Java™ Platform also includes some profiling facilities. The most popular of these "built-in" profiling tools are The -Xprof Profiler and the HPROF profiler (for uses with HPROF see also Heap Analysis Tool).

The -Xprof profiler is the HotSpot profiler. HotSpot works by running Java code in interpreted mode, while running a profiler in parallel. The HotSpot profiler looks for "hot spots" in the code, i.e. methods that the JVM spends a significant amount of time running, and then compiles those methods into native generated code.

Basically, if any method is found to be at the top of the stack more than a few times, then the application can probably benefit from having that method compiled.

§         Each thread has it's profile recorded separately, and is output separately on thread termination; there is no combined view of the application runtime.

§         Only the top runtime stack method at sample time is identified, so there is no contextual information; being told that java.lang.String.equals is a bottleneck in application is almost useless since many methods which call String.equals() is causing most of the trouble. (Note that it is fine for HotSpot, HotSpot doesn't care about context, and it just cares that String.equals() is a bottleneck, so that it knows it should spend some time compiling that method to native code.)

Only method execution is profiled; there is no object creation, garbage collection, or thread conflict profiling