Skip navigation.
Downloads | Product Documentation | Support

Using JRockit JDK

# Using the BEA JRockit Memory Management System

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 Mark-and-Sweep Garbage Collection Model
- Garbage Collector Options
- The Dynamic Garbage Collector
- Using Backward-compatible Garbage Collectors
- Overriding Garbage Collectors
- Viewing Garbage Collection Behavior

# The Mark-and-Sweep Garbage Collection Model

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:

1. The "mark" phase, traverses all pointers, starting at the accessible roots of a program (conventionally, globals, the stack, and registers) and marks each object traversed.
2. The "sweep" phase, re-walks the heap linearly and removes all objects that are not marked.

# Garbage Collector Options

JRockit's garbage collector can be a combination of the following two garbage collector options:

- Two-generational Garbage Collection
- Single-generational Garbage Collection

and two garbage collection algorithms:

- Concurrent Garbage Collection
- Parallel Garbage Collection

## Two-generational Garbage Collection

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.

## Single-generational Garbage Collection

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.

## Concurrent Garbage Collection

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.

## Parallel 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

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.

Table 3-1 -Xgcprio Option Priorities

Priority | Description
--- | ---
Application Throughput (`-Xgcprio:throughput`) | 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.
Pause Time (`-Xgcprio:pausetime`) | 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 `-Xpausetarget` to set a target length for the garbage collection pauses.

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.

# Using Backward-compatible Garbage Collectors

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:

- Single-spaced Concurrent (`-Xgc:singlecon`; this is the default garbage collector when BEA JRockit is run in the `-client` mode)
- Generational Concurrent (`-Xgc:gencon`)
- Parallel (`-Xgc:parallel`)

## Overriding Garbage Collectors

Setting `-Xgc` will override `-Xgcprio` and any default settings.

# Garbage Collector Selection Matrix

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.

Table 3-2 Garbage Collector Selection Matrix

If You... | Use this Garbage Collector... | Or use...
--- | --- | ---
Want to have as short pause times as possible. Are willing to trade (some) application thoughput for shorter pauses. Have a single CPU machine with a lot of memory. Want better application throughput than possible with single-spaced concurrent. | `-Xgcprio:pausetime` | `-Xgc:singlecon` `-Xgc:gencon`
Using a machine with four CPUs or better or a single CPU machine with a lot of memory. Can tolerate the occasional long pause. Need to maximize application throughput. | `-Xgcprio:throughput` | `-Xgc:parallel`
Do not want a dynamic garbage collector. | `-Xgc:parallel` | `-Xgc:singlecon`

# Viewing Garbage Collection Behavior

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.

- If you want to view garbage collection during real-time, use the BEA JRockit Management Console tool. See the Using BEA JRockit Management Console document for information on how to use the tool.
- If you want information about the garbage collection during run-time, set the `-Xverbose:memory` option at startup. The information will appear in your console window.
- If you want to see a comprehensive report of garbage collection activity, enter the `-Xgcreport` option at startup. With this option JRockit prints a comprehensive garbage collection report when application run is completed.
- If you want to see the garbage collection activity when it occurs, enter the `-Xgcpause` option.This option causes the VM to print a line each time Java threads are stopped for garbage collection.

You can combine the `-Xgcreport` and `-Xgcpause` at start up to examine the memory behavior of your application, for example, like this:

`java -Xgcreport -Xgcpause myClass`