Ergonomics in the 5.0 JavaTM Virtual Machine

1. Introduction

In the J2SE platform version 5 the default selection for the garbage collector, heap size, and runtime compiler have changed for some platforms. 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 a desired behavior and depends on the garbage collector to dynamically tune the sizes of the heap to meet the specified behavior. This combination of platform dependent default selections and the garbage collection tuning that uses desired behavior is referred to in this document as “ergonomics”.

This document is a companion to the document Tuning Garbage Collection with the 5.0 Java ™ Virtual Machine . Familiarity with that tuning document is assumed although familiarity with the previous version of that document for the 1.4.2 Java Virtual Machine should suffice.

1. Garbage collector, heap, and runtime compiler

In the J2SE platform version 1.4.2 by default the following selections were made

• Serial garbage collector

• Heap sizes

• initial heap size of 4 Mbyte

• maximum heap size of 64 Mbyte

• Client runtime compiler

In the J2SE platform version 5.0 a class of machine referred to as a server-class machine has been defined as a machine with

• 2 or more physical processors

• 2 or more Gbytes of physical memory

On server-class machines by default the following are selected.

• Throughput garbage collector

• Heap sizes

• initial heap size of 1/64 of physical memory up to 1Gbyte

• maximum heap size of ¼ of physical memory up to 1Gbyte

• Server runtime compiler

The definition of a server-class machine applies to all platforms with the exception of 32 bit platforms running a version of the Windows™ operating system. On all other platforms the default values are the same as the default values for version 1.4.2. Below is a table showing the choices made for the runtime compiler on difference platforms.

Platform	Operating System	Default	Default if server class
Sparc™ (32-bit)	Solaris™	Client	Server
I586	Solaris™	Client	Server
	Linux™	Client	Server
	Windows™	Client	Client1
Sparc™ (64-bit)	Solaris™	Server	Server2
AMD™ (64-bit)	Linux™	Server	Server2
	Windows™	Server	Server2
IA-64	Linux™	Server	Server2
	Windows™	Server	Server2

“Client” means the client runtime compiler is used. “Server” means the server runtime compiler is used. Under “Default if server class” Client¹ means that the policy was chosen to use the client runtime compiler even on a server class machine. This choice was made because historically client applications (i.e., interactive applications) were run more often on this combination of platform and operating system. Where Server² is indicated, only the server runtime compiler is supported.

the

1. Behavior based tuning

Prior to the J2SE platform version 5.0 tuning for garbage collection consisted principally of specifying the size of the the overall heap and possibly the size of the generations in the heap. Other controls for tuning garbage collection include the size of the survivor spaces in the young generation and the threshold for promotion from the young generation to the old generation. Tuning required of a series of experiments with different values of these parameters and the use of specialized tools or just good judgment to decide when garbage collection was performing well.

In version 5.0 two parameters based on the desired behavior of the application have been introduced. These are

• Maximum pause time goal

• Application throughput goal.

Setting these goals can be used to tune garbage collection. It should be emphasized that the goals cannot always be met. The application requires heap large enough to at least hold all of the live data. That minimum heap size my preclude reaching these desired goals.

3.1 Maximum pause time goal

The pause time is the duration during which the garbage collector stops the application and recovers space that is no longer in use. The intent of the maximum pause time goal is to limit the longest of these pauses. An average time for pauses and a variance on that average is maintained by the garbage collector. The average is taken from the start of the execution but is weighted so that more recent pauses count more heavily. If the average plus the variance of the pause times is greater than the maximum pause time goal, then the garbage collector considers that the goal is not being met.

The maximum pause time goal is specified with the command line flag

-XX:MaxGCPauseMillis=<nnn>

This is interpreted as a hint to the garbage collector that pause times of <nnn> milliseconds or less are desired. The garbage collector will adjust the Java heap size and other garbage collection related parameters in an attempt to keep garbage collection pauses shorter than <nnn> milliseconds. By default there is no maximum pause time goal. These adjustments may cause the garbage collector to occur more frequently, reducing the overall throughput of the application. In some cases the desired pause time goal cannot be met.

 

The throughput collector is a generational collector so there are separate collections for the young generation and the old generation. Averages and variances are kept separately for each generation. The maximum pause time goal is applied to the average plus the variance of the collections of each generation separately. Each generation may separately fail to meet the pause time goal.

 

3.2 Throughput goal

The throughput goal is measured in terms of the time spent collecting garbage and the time spent outside of garbage collection (referred to as application time). The goal is specified by the command line flag

-XX:GCTimeRatio=<nnn>

The ratio of garbage collection time to application time is

 

1 / (1 + <nnn>)

 

For example -XX:GCTimeRatio=19 sets a goal of 1/20^th or 5% of the total time for garbage collection.

 

The time spent in garbage collection is the total time for both the young generation and old generation collections combined. If the throughput goal is not being met, the sizes of the generations are increased in an effort to increase the time the application can run between collections.

 

3.3 Footprint goal

If the throughput and maximum pause time goals have been met, the garbage collector reduces the size of the heap until one of the goals (invariably the throughput goal) cannot be met. The goal that is not being met is then addressed.

1. Tuning Strategy

Do not choose a maximum value for the heap unless you know that you need a heap greater than the default maximum heap size. Choose a throughput goal that is sufficient for you application.

 

The heap will grow or shrink to a size that will support the chosen throughput goal. Some oscillations in the size of the heap during initialization and during a change in the application's behavior can be expected.

 

If the heap grows to its maximum, in most cases that means that the throughput goal cannot be met within that maximum heap size. Set the maximum heap size to a value that is close to the total physical memory on the platform but which does not cause swapping of the application. Execute the application again. If the throughput goal is still not met, then the goal for the application time is too high for the available memory on the platform.

 

If the throughput goal can be met, but there are pauses that are too long, select a maximum pause time goal. Choosing a maximum pause time goal may mean that your throughput goal will not be met so choose values that are an acceptable compromise for the application.

 

It is typical that the size of the heap will oscillate as the garbage collector tries to satisfy competing goals. This is true even if the application has reached a steady state. The pressure to achieve a throughput goal (which may require a larger heap) competes with the goals for a maximum pause time and a minimum footprint (which both may require a small heap).

 

1. Other changes

   5.1 Thread-local allocation buffers

   The resizing of thread-local allocation buffers has been re-implemented. When a thread-local allocation buffer fills, the size of the new buffer depends on the allocation pattern of the thread. Threads that do allocate more memory will get larger buffers.