Garbage Collector Ergonomics

The following changes take effect with J2SE 5.0.

1. On server-class machines running the server VM , the garbage collector (GC) has changed from the previous serial collector (-XX:+UseSerialGC ) to a parallel collector (-XX:+UseParallelGC ). You can override this default by using the -XX:+UseSerialGC command-line option to the java command.

2. On server-class machines running either VM (client or server) with the parallel garbage collector (-XX:+UseParallelGC ) the initial heap size and maximum heap size have changed as follows.

    

   initial heap size:

   Larger of 1/64th of the machine's physical memory on the machine or some reasonable minimum. Before J2SE 5.0, the default initial heap size was a reasonable minimum, which varies by platform. You can override this default using the -Xms command-line option.

   maximum heap size:

   Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default maximum heap size was 64MB. You can override this default using the -Xmx command-line option.

    

   ---

   Note: The boundaries and fractions given for the heap size are correct for J2SE 5.0. They are likely to be different in subsequent releases as computers get more powerful.
   

   ---

   
   

3. The parallel garbage collector (UseParallelGC ) throws an out-of-memory exception if an excessive amount of time is being spent collecting a small amount of the heap. To avoid this exception, you can increase the size of the heap. You can also set the parameters -XX:GCTimeLimit= time-limit and -XX:GCHeapFreeLimit= space-limit where:

    

   time-limit :

   The upper limit on the amount of time spent in garbage collection in percent of total time (default is 98).

   space-limit :

   The lower limit on the amount of space freed during a garbage collection in percent of the maximum heap (default is 2).
   
   

4. The implementation of -XX:+UseAdaptiveSizePolicy used by default with the -XX:+UseParallelGC garbage collector has changed to consider three goals:

1.  
   • a desired maximum GC pause goal
   • a desired application throughput goal
   • minimum footprint

The implementation checks (in this order):

1.  
   1. If the GC pause time is greater than the pause time goal then reduce the generations sizes to better attain the goal.
   2. If the pause time goal is being met then consider the application's throughput goal. If the application's throughput goal is not being met, then increase the sizes of the generations to better attain the goal.
   3. If both the pause time goal and the throughput goal are being met, then the size of the generations are decreased to reduce footprint.

Flags

-XX:MaxGCPauseMillis= nnn

A hint to the virtual machine that pause times of nnn milliseconds or less are desired. The VM will adjust the java heap size and other GC-related parameters in an attempt to keep GC-induced pauses shorter than nnn milliseconds. Note that this may cause the VM to reduce overall throughput, and in some cases the VM will not be able to meet the desired pause time goal.

By default there is no pause time goal. There are definite limitations on how well a pause time goal can be met. The pause time for a GC depends on the amount of live data in the heap. The minor and major collections depend in different ways on the amount of live data. This parameter should be used with caution. A value that is too small will cause the system to spend an excessive amount of time doing garbage collection.

 

-XX:GCTimeRatio= nnn

A hint to the virtual machine that it's desirable that not more than 1 / (1 + nnn) of the application execution time be spent in the collector.

For example -XX:GCTimeRatio=19 sets a goal of 5% of the total time for GC and throughput goal of 95%. That is, the application should get 19 times as much time as the collector.

By default the value is 99, meaning the application should get at least 99 times as much time as the collector. That is, the collector should run for not more than 1% of the total time. This was selected as a good choice for server applications. A value that is too high will cause the size of the heap to grow to its maximum.

Suggested strategy

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

In an ideal situation the heap will grow to a value (less than the maximum) that will support the chosen throughput goal.

If the heap grows to its maximum, the throughput cannot be met within that maximum. Set the maximum heap as large as you can, but no larger than the size of physical memory on the platform, and execute the application again. If the throughput goal can still not be met, then it 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 pause time goal. This will likely mean that your throughput goal will not be met, so choose values that are an acceptable compromise for the application.