Using WebLogic JRockit 8.1 SDK
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:
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 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.
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 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.
This section describes the four garbage collectors available in WebLogic JRockit JVM. These collectors are:
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.
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:
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.
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 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.
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:
When started, JRockit will run with the specified garbage collector.
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
).
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.
Table 4-2 lists the pros and cons of each garbage collector.
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.
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.
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.
-Xgcreport
option at startup. This option causes WebLogic JRockit JVM to print a comprehensive garbage collection report at program completion. -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