Sun Microsystems 820434310 manual Tracing Garbage Collection, Other Garbage Collector Settings

Managing Memory and Garbage Collection

Tracing Garbage Collection

The two primary measures of garbage collection performance are throughput and pauses. Throughput is the percentage of the total time spent on other activities apart from GC. Pauses are times when an application appears unresponsive due to GC.

Two other considerations are footprint and promptness. Footprint is the working size of the JVM process, measured in pages and cache lines. Promptness is the time between when an object becomes dead, and when the memory becomes available. This is an important consideration for distributed systems.

A particular generation size makes a trade-off between these four metrics. For example, a large young generation likely maximizes throughput, but at the cost of footprint and promptness. Conversely, using a small young generation and incremental GC will minimize pauses, and thus increase promptness, but decrease throughput.

JVM diagnostic output will display information on pauses due to garbage collection. If you start the server in verbose mode (use the command asadmin start-domain --verbose domain), then the command line argument -verbose:gc prints information for every collection. Here is an example of output of the information generated with this JVM flag:

[GC 50650K->21808K(76868K), 0.0478645 secs] [GC 51197K->22305K(76868K), 0.0478645 secs] [GC 52293K->23867K(76868K), 0.0478645 secs] [Full GC 52970K->1690K(76868K), 0.54789968 secs]

On each line, the first number is the combined size of live objects before GC, the second number is the size of live objects after GC, the number in parenthesis is the total available space, which is the total heap minus one of the survivor spaces. The final figure is the amount of time that the GC took. This example shows three minor collections and one major collection. In the first GC, 50650 KB of objects existed before collection and 21808 KB of objects after collection. This means that 28842 KB of objects were dead and collected. The total heap size is 76868 KB. The collection process required 0.0478645 seconds.

Other useful monitoring options include:

■-XX:+PrintGCDetails for more detailed logging information

■-Xloggc:file to save the information in a log file

Other Garbage Collector Settings

For applications that do not dynamically generate and load classes, the size of the permanent generation has no effect on GC performance. For applications that dynamically generate and load classes (for example, JSP applications), the size of the permanent generation does affect GC performance, since filling the permanent generation can trigger a Full GC. Tune the maximum permanent generation with the -XX:MaxPermSize option.

86 Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide • January 2009