Pick up performance with generational garbage collection

Use the appropriate Java HotSpot VM 1.3.1 parameters to improve throughput

1 2 Page 2
Page 2 of 2

Here is sample output from the above awk script:

Minor       Major       Alive       Freed
0.0484179   0.0         20909       19640
0.0411095   0.0         21405       19792
0.0846190   0.0         22995       18698
0.0492838   0.0         23672       19611
0.0         0.1452965   1749        42211
0.0310949   0.0         2810        19227
0.0469624   0.0         3657        19441
0.0580108   0.0         4847        19098

I imported the awk script's output into MS Excel. Figure 6 illustrates a graph created from the two lefthand columns. It shows the frequency of minor and major collections plus the amount of time required to perform the GC (i.e., the pauses).

Figure 6. Sample graph of minor/major collections

Figure 7 illustrates a graph created from the two righthand columns. It shows the amount of memory live objects consumed following each GC, as well as the amount of memory freed when dead objects were reclaimed.

Figure 7. Sample graph of GC behavior

Tenure distribution

After objects have been collected several times, they become tenured and are promoted to the old generation. You can use the -XX:+PrintTenuringDistribution parameter to display the information the JVM uses during its tenure calculations.

The JVM attempts to keep a target percentage of the survivor spaces empty, as defined by the -XX:TargetSurvivorRatio parameter. The default value is 50, meaning that the goal is to empty one-half (50 percent) of the survivor capacity following GC. The JVM computes the desired survivor size as shown below, and then computes the object threshold. An object's threshold accounts for the number of times an object is copied before it is tenured; this is recalculated at each collection:

    (survivor_capacity * TargetSurvivorRatio) / 100 * sizeof(a pointer)

Below is sample output when running java -verbosegc -XX:+PrintTenuringDistribution MyApp. In the first GC, the desired survivor size is 393,216 bytes (384 KB) and the threshold is 1, meaning that objects will be tenured following one collection. Then the garbage collector goes through the ages, the number of times the collector decides not to promote:

Desired survivor size 393216 bytes, new threshold 1 (max 32)
- age   1:   509624 bytes,   509624 total
 20288K->497K(64768K), 0.0147963 secs]
Desired survivor size 393216 bytes, new threshold 32 (max 32)
- age   1:   169616 bytes,   169616 total
 27697K->6997K(64768K), 0.0038858 secs]
Desired survivor size 393216 bytes, new threshold 32 (max 32)
- age   1:   191392 bytes,   191392 total
- age   2:    52944 bytes,   244336 total
 27285K->7070K(64768K), 0.0046738 secs]
Desired survivor size 393216 bytes, new threshold 1 (max 32)
- age   1:   733488 bytes,   733488 total
- age   3:    52944 bytes,   786432 total
 27358K->7662K(64768K), 0.0148100 secs]

In the first GC above, objects occupying 509,624 bytes have already been copied once, meaning that they are in the first age bucket (age 1). In the third GC, there are objects occupying 191,392 bytes in the first age bucket and objects occupying 52,944 bytes in the second age bucket. Since the threshold is 32 during the third GC, you see that the objects were not tenured, because in the fourth GC there are objects occupying 52,944 bytes in the third age bucket.

(See "Sidebar 2: Performance Test Program" at the end of this article for information on Ed Ort's HeapTest program used to test parameters in this article.)

Take out the trash

Ordinarily, the Java developer doesn't have to be concerned with the complexity of memory allocation and GC within the JVM. However, understanding aspects of this hidden implementation can help you ensure effective resource use. Garbage collection algorithms make assumptions about the way applications use objects. The HotSpot JVM's tunable parameters let you adjust the GC algorithms to better meet your application's behavior characteristics. Sometimes just adding the -server parameter to switch from the default HotSpot Client JVM to the HotSpot Server JVM can improve throughput of WebLogic applications by 20 percent or more.

Stay tuned for the Java HotSpot VM 1.4 release, which will extend the train, or incremental, garbage collector algorithm to perform GC in parallel.

Ken Gottry is a senior infrastructure architect with NerveWire, Inc. He has 30 years experience with systems ranging from mainframes to minicomputers to servers to desktops. For the past 10 years, he has focused on designing, implementing, and tuning distributed, multitiered, and Web-based systems. As a performance engineer consulting to numerous G2K (Global 2000) firms, he has assessed and tuned networks, Web servers, application servers, and JVMs running on the Solaris Operating Environment. You can visit Ken's Website at http://www.gottry.com.

Learn more about this topic

This story, "Pick up performance with generational garbage collection" was originally published by JavaWorld.

Copyright © 2002 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2