Using JRockit JDK
Memory management relies on effective "garbage collection," the process of clearing dead objects from the heap, thus releasing that space for new objects. BEA JRockit uses a dynamic garbage collector that is based upon one of two priorities that you set: application throughput or duration of the pause times caused by garbage collection. The dynamic garbage collector uses predefined heuristics to determine, in runtime, which garbage collection algorithm to use for each application.
In some instances, dynamic garbage collection might not be the most effective way to recycle memory. In those cases, BEA JRockit also provides a number of "static" garbage collectors that can be started by specifying the actual collector (-Xgc:<
collectorName
>
) at startup.
This section describes how to use all of these garbage collection methods. It contains information on the following subjects:
The garbage collector models in JRockit are all mark-and-sweep garbage collectors that run either as generational or single-spaced; that is, with or without a "nursery" (see Two-generational Garbage Collection, below). The mark-and-sweep garbage collection is implemented as either a concurrent or parallel algorithm.
A mark-and-sweep garbage collector frees all unreferenced objects and works as described in these steps:
JRockit's garbage collector can be a combination of the following two garbage collector options:
and two garbage collection algorithms:
During a two-generational garbage collection, the heap is divided into two sections: an old generation and a young generation—also called the "nursery." Objects are allocated in the nursery and when it is full, JRockit stops all Java threads and moves the live objects from the nursery, young generation, to the old generation.
The single-spaced option of garbage collection means that all objects live out their lives in a single space on the heap, regardless of their age. In other words, a single-spaced garbage collector does not have a nursery.
The concurrent garbage collection algorithm does its marking and sweeping "concurrently" with all other processing; that is, it does not stop Java threads to do the complete garbage collection.
The parallel garbage collection algorithm stops Java threads when the heap is full and uses every CPU to perform a complete mark and sweep of the entire heap. A parallel garbage collector can have longer pause times than concurrent garbage collectors, but it maximizes application throughput. Even on single CPU machines, this maximized performance makes parallel the recommended garbage collector, provided that your application can tolerate the longer pause times.
The dynamic garbage collector is the default garbage collector in JRockit and it combines the options and algorithms described above within the mark-and-sweep model to perform a garbage collection. Depending upon the heuristics used, the garbage collector will employ a two-generational or single-spaced collector with either a concurrent or parallel mark phase and a concurrent or parallel sweep phase.
The main benefit of a dynamic garbage collector is that the only determination you need to make for the best performance of your application is whether your application responds best to optimal throughput or minimized pause times during garbage collection. You do not need to understand the garbage collection algorithms themselves, or the various permutations thereof, just the behavior of your application.
To start the dynamic garbage collector, use the -Xgcprio
command line option with either the throughput
or pausetime
parameter, depending upon which priority you want to use:
-Xgcprio:<throughput|pausetime>
If you set the pausetime option, you can also specify a target pause time for the garbage collection, for example:
-Xgcpausetarget=400ms
Table 3-1 describes the priorities under which you can start a dynamic garbage collector and the parameters used to select that priority.
Upon selecting the priority and starting the JVM, the dynamic garbage collector will then try to choose the garbage collection state that optimizes performance based upon the priority. It will seek modes that optimize throughput when -Xgcprio:throughput
is set or that minimize the pause times (as much as possible) when -Xgcprio:pausetime
is set.
In some cases, you might not want to use a dynamic garbage collector. In those cases, you can specify one of the three static garbage collectors. The static garbage collectors will not attempt to optimize performance by changing algorithms. These garbage collectors are the original garbage collectors of earlier versions of JRockit. Depending on the circumstances, the performance of these collectors might meet your needs better than the dynamic garbage collector. Additionally, if you want to use scripts written for the earlier versions of JRockit that implement these collectors, those scripts will continue to work without requiring any modification—unless they use the copying garbage collectors, which are no longer available.
The available garbage collectors (and the command to start them) are:
-Xgc:singlecon
; this is the default garbage collector when BEA JRockit is run in the -client
mode)-Xgc:gencon
)-Xgc:parallel
)Setting -Xgc
will override -Xgcprio
and any default settings.
Table 3-2 is a matrix that you can use to determine which garbage collector is right for your application. Use the If You... column to locate a condition that matches what you want for your application and select the garbage collector indicated in the Use this Garbage Collector... column. The third column, Or use..., lists an alternate supported garbage collector.
To observe garbage collection behavior, use one or all of the possibilities described here. Using this helps you evaluate the effectiveness of the selected garbage collector and makes it possible to make correct tuning decisions.
-Xverbose:memory
option at startup. The information will appear in your console window.-Xgcreport
option at startup. With this option JRockit prints a comprehensive garbage collection report when application run is completed.-Xgcpause
option.This option causes the VM to print a line each time Java threads are stopped for garbage collection.