Using WebLogic JRockit 8.1 SDK

Selecting and Running a Memory Management System

Memory management, known as "garbage collection" is the process of clearing "dead" objects from the heap, thus releasing that space for new objects. Effective memory management ensures efficient processing This section includes information on the following subjects:

Memory Management Terminology

Before continuing, there are some terms you should understand. You may already be familiar with some of the terms, especially if you have read any other documents about garbage collectors.

Thread-local allocation

Thread-local allocation removes object allocation contention and reduces the need to synchronize between thread performing allocations on the heap. It also gives increased cache performance on a multi-CPU system, because it reduces the risk of two threads running on different CPUs having to access the same memory pages at the same time.

Thread-local allocation is not the same thing as thread-local objects, but many people tend to confuse the two terms. Thread-local allocation does not determine whether the objects can be accessed from a single thread only (that is, thread-local objects); thread-local allocation means that the thread has an area of its own where no other thread will create new objects. The objects that the thread creates in that area may still be reached from other threads.

Pause time

Garbage collector pause time is the length of time that the garbage collector stops all Java threads during a garbage collection. The longer the pause, the more unresponsive your system will be. The worst pause time and the average pause time are the two most interesting values you can use for tuning the system.

Memory throughput

Memory throughput measures the time between when an object is no longer referenced and the time that it's reclaimed and returned as free memory. The higher the memory throughput the shorter is the time between the two events. Moreover, the higher the memory throughput the smaller the heap you will need.

WebLogic JRockit JVM Garbage Collectors

This section describes the four garbage collectors available in WebLogic JRockit JVM. These collectors are:

Generational Copying

A generational copying garbage collector divides the memory into two or more areas called "generations". Instead of allocating objects in one single space and garbage collecting that whole space when it gets full, most of the objects are allocated in the "young generation", called the nursery. As most objects die young, most of the time it will be sufficient to collect only the nursery and not the entire heap.

A generational copying garbage collector is specifically designed as a lightweight alternative for use on single CPU systems with a small (less then 128 MB) heap. It is suitable for testing applications on your desktop machine; however for a deployment environment with multiple processors and/or a large heap size (in excess of 128 MB), another garbage collector would in most cases be more efficient.

Concurrent Garbage Collectors

A concurrent garbage collector does its work in parallel with ordinary work; that is, it does not stop all Java threads to do the complete garbage collection. Most garbage collectors today are "stop-the-world," or parallel, collectors and are not very efficient; for example, if you have a large heap and use a parallel collector, if you need to collect the whole heap, you might experience pauses lasting up to several seconds, depending on the heap size. Concurrent garbage collectors are designed to rectify this condition.

WebLogic JRockit can employ two types of concurrent garbage collectors:

Single Spaced Concurrent

A single spaced concurrent garbage collector (-Xgc:singlecon) completely eliminates garbage collection pauses. If you use these garbage collectors, the heaps can be gigabyte-size and still long pauses will not occur. However, to achieve this elimination of pauses, concurrent garbage collectors trade memory throughput; that is, it takes longer between the time the object is referenced the last time and the system detects and reclaims it. The natural consequence of this is that you will most likely need a larger heap with a concurrent garbage collector than you need with any other. In addition, if your ordinary Java threads create more garbage than the concurrent garbage collector manages to collect, unanticipated pauses will occur while the Java threads are waiting for the garbage collector to complete its cycle.

Generational Concurrent

With generational concurrent garbage collectors (-Xgc:gencon), objects are allocated in the young generation (the nursery). When the nursery is full, WebLogic JRockit JVM "stops-the-world" and moves the live objects in the young generation to the old generation. An old collector thread runs in the background all the time; it marks objects in the old space as live and removes the dead objects, returning them to WebLogic JRockit JVM as free space. The advantage of the generational concurrent garbage collector compared to the single spaced concurrent garbage collector is that it has a higher memory throughput.

Parallel

Parallel garbage collectors (-Xgc:parallel) stop all Java threads when the heap is full and use every CPU to perform a complete garbage collection of the entire heap. A parallel collector can have longer pause times than concurrent collectors, but it maximizes 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.

Starting a Garbage Collector

To start a garbage collector, simply include at the command line the -Xgc option and the type of collector you want to use. Table 4-1 lists these arguments:

Table 4-1 Garbage Collector Implementation Options

Garbage Collector	Option
Generational Copying	`-Xgc:gencopy`
Single Spaced Concurrent	`-Xgc:singlecon`
Generational Concurrent	`-Xgc:gencon`
Parallel	`-Xgc:parallel`

When started, JRockit will run with the specified garbage collector.

Default

If the garbage collector has not been set and the maximum heap size (set by using -Xmx or using the default as described above) is less than 128 MB, the default garbage collector is generational copying (-Xgc:gencopy); otherwise the default is generational concurrent (-Xgc:gencon).

Choosing a Garbage Collection Method

Each of the four garbage collectors has its benefits and its drawbacks. In an effort to help you choose the collector that best suits your needs, this section discusses the pros and con of each collector and provides a matrix to help you decide which one to use.

Pros and Cons

Table 4-2 lists the pros and cons of each garbage collector.

Table 4-2 Garbage Collector Pros and Cons

Garbage Collector	Pros	Cons
Generational Copying	Works well with single CPU systems with a heap smaller than 128mB. Packs small objects together during each collection. Good for testing on a single machine. Default garbage collector for heaps less than 128 mB.	Not effective with large (>128mB) heaps. Lacks speed and scaleability. Moves objects back and forth between the two semispaces so it doesn't fully utilize the whole heap. Not recommended in a deployment environment.
Single Spaced Concurrent	Virtually removes all pauses. Can handle gigabyte-sized heaps.	Trades memory for fewer pauses. If ordinary Java threads create more garbage than this collector can collect, pauses occur while these threads are waiting for the collector to complete its cycle. Only effective so long as the program doesn't run out of memory during collection.
Generational Concurrent	Virtually removes all pauses. Has a higher memory throughput than single spaced concurrent garbage collector. Reduces the risk of running out of allocatable memory during collection because the old space is not filled at the same speed.	Trades memory for fewer pauses. If ordinary Java threads create more garbage than this collector can collect, pauses occur while these threads are waiting for the collector to complete its cycle.
Parallel	Uses all processors during collection, thus maximizing memory throughput.	"Stop the world" might cause a longer than desirable pause in processing.

Garbage Collector Selection Matrix

Table 4-3 is a matrix that you can use to determine which garbage collector is right for your WebLogic JRockit JVM implementation. Use the If... column to locate a condition that matches your implementation and select the garbage collector indicated in the Select this Method... column.

Table 4-3 Garbage Collector Selection Matrix

If You...	Select this Garbage Collector...
Want lightweight alternative for use on single CPU systems with a small (less then 128 mB) heap. Are testing applications on your desktop machine.	Generational Copying
Cannot tolerate pauses of any length. Employ gigabyte-sized heaps. Willing to trade memory thoughput for eliminating pauses. Have a single CPU machine with a lot of memory.	Single Spaced Concurrent
Cannot tolerate pauses of any length. Employ gigabyte-sized heaps. Willing to trade some memory thoughput for eliminating pauses. Want better memory throughput than possible with Single Spaced Concurrent. Are not sure that the other three methods would be adequate given how you've implemented WebLogic JRockit JVM.	Generational Concurrent
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 memory throughput	Parallel

Tuning for Garbage Collection

The effectiveness of the garbage collector depends upon a number of memory management parameters you can set; for example, heap size and thread allocation. To provide the optimal out-of-the-box experience, WebLogic JRockit comes with default values for these—and other—settings that adapt automatically to the specific platform on which you are running the JVM. However, you can modify these values to improve performance by specifying at the command line any of the options listed in Tuning WebLogic JRockit JVM in Tuning WebLogic JRockit JVM.

Viewing Garbage Collection Activity

To observe garbage collection activity, use one or both of the options described here. Using these options will help you evaluate the effectiveness of the selected garbage collector and make necessary tuning decisions.

If you want to see a comprehensive report of garbage collection activity, enter the -Xgcreport option at startup. This option causes WebLogic JRockit JVM to print a comprehensive garbage collection report at program completion.
If you want to see garbage collection activity when it occurs, enter the -Xgcpause optiom.This option causes the VM to print a line each time Java threads are stopped for garbage collection.

Combining these two options is a very good way of examining the memory behavior of your application; for example:

-java -Xgcparallel -Xgcreport -Xgcpause myClass