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 (
>) at startup.
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.
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 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.
Table 3-1 describes the priorities under which you can start a dynamic garbage collector and the parameters used to select that priority.
The garbage collector is optimized for application throughput. This means that the garbage collector works as effectively as possible, giving as much CPU resources to the Java threads as possible. This may, however, cause non-deterministic pauses when the garbage collector stops all Java threads for garbage collection.The throughput priority should be used when non-deterministic pauses do not impact the application's behavior.
The garbage collector is optimized to limit the length of each garbage collection pause where all Java threads are stopped for garbage collection. This may result in lower application throughput, as the garbage collector uses more CPU resources in total than when running with the throughput priority. The pausetime priority should be used when the application depends on an even performance. Use
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.
-Xgc:singlecon; this is the default garbage collector when BEA JRockit is run in the
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:memoryoption at startup. The information will appear in your console window.
-Xgcreportoption at startup. With this option JRockit prints a comprehensive garbage collection report when application run is completed.
-Xgcpauseoption.This option causes the VM to print a line each time Java threads are stopped for garbage collection.