HP

HPjmeter 4.1 User's Guide

English
  HPjmeter 4.1 User's Guide > Chapter 6 Analyzing Garbage Collection Data   

Basic Garbage Collection Concepts

A basic principle behind the design of the garbage collector is that objects tend to be either short-lived or else persist for the lifetime of an application run. By separating persistent objects from short-lived objects and moving them to designated spaces, the garbage collector can free memory for use by the application (improving efficiency of memory use), and avoid examining every object each time a collection is done (reduce garbage collection overhead).

Through a system of identification and classification, an object ages each time it survives a garbage collection event. After surviving a certain number of garbage collection events, the object is considered old — at which point, it is moved from the young to the old area of the heap.

A scavenge is a garbage collection event where only short-lived, unused objects are collected from the young heap area. Typically, scavenges are significantly faster than a full garbage collection, which involves examining all objects in the entire heap.

Key to Garbage Collection Types Recognized by HPjmeter

HPjmeter reports numerous types of garbage collection. You may see references in HPjmeter to GC types in data summaries or visualizers, so it helps to become familiar with them.

Table 6-5 Common Garbage Collection Types Recognized by HPjmeter

Concurrent Mark-SweepA garbage collection performed in the old area of the heap as a background thread which does its work with few pauses in the application run.
Parallel ScavengeOnly objects from the young generation are collected using a multi-threaded garbage collector.
ScavengeObjects from the young generation only are collected using a single thread.
Scavenge during CMSCollection in the young generation occurs when a CMS operation is set to collect in the old generation. The pauses for the young generation collection and the old generation collection occur independently and cannot overlap.
Incomplete Concurrent Mark-Sweep Occurs when a background thread is performing a garbage collection in the old area, but is interrupted when the JVM determines that a full GC is needed.
Old Expanded Full GCNecessary when the old area is expanded on the most recent scavenge. Typically, this happens when -Xms and -Xmx are not the same.
Perm FullFull GC necessary because the space reserved for metadata is full.
Train FullFull GC necessary because intermediate space assigned to collection using the train algorithm is full.
Old Too FullFull GC performed when the garbage collector determines that space for old objects is insufficient to support a successful scavenge. This determination is reached without analyzing the heap.
Old FullFull GC performed when the garbage collector determines that space for old objects is insufficient to support a successful scavenge. This determination is reached by analyzing the heap.
System.gcThe application calls method System.gc() to force a full garbage collection.
Heap Dump Triggered GCA full GC is performed as a result of a signal sent to the JVM to collect a heap dump.
JVMTI force GCA garbage collection is performed as a result of invoking the ForceGarbageCollection function of JVMTI.
Other Full GCA full garbage collection of unknown type and cause.
CMS First STWMark the first pause during a concurrent collection cycle. Called the initial mark, this identifies the initial set of live objects directly reachable from the application code.
CMS Second STWMark the second pause during a concurrent collection cycle. Called the re-mark, this finalizes marking by revisiting any objects that were modified during the concurrent marking phase.

 

See also Data Collection with -Xverbosegc.

For an explanation of Java memory terminology, see the Sun Developer Network publication Memory Management in the Java HotSpot™ Virtual Machine (http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf)

Understanding the Summary Presentation of GC Data

To view the summary presentation of GC data, double-click on the data representation in the main panel. A window will open to display the data.

The following image shows a summary of .vgc data collected using the -Xverbosegc option and displayed under the Summary tab. Important aspects of the summary data are defined below the image.

Figure 6-2 Summary Panel Showing Garbage Collection Statistics

Summary Panel Showing Garbage Collection Statistics

Heap Capacity  Initial, final, and peak sizes allocated for various organizational spaces in the heap.

Peak Usage of Capacity  The highest percentage of actual use by the application of the heap at its final capacity configuration. A rule of thumb for optimal utilization would be to have the eden space at 100% with the survivor and old spaces showing some reserve capacity, depending on the application.

GC Activity Summary  In this example, a comparison of scavenges and full garbage collection of the old and permanent generations, showing number of GC occurrences, duration, and memory usage for each GC type displayed.

Duration of the Measurement  The approximate, elapsed, wall clock time for the entire data collection.

Measurement Enabled and Measurement Disabled  “Measurement enabled” refers to the total time during which zero preparation GC data collection has been activated during the session thus far. “Measurement disabled” refers to the total time during which no data was collected (zero preparation GC data collection is not in use). These values are visible on this tab when zero preparation GC data collection is used during a monitoring session. They are not present when collecting GC data using the -Xverbosegc or -Xloggc options on the command line.

Total Bytes Allocated  The total amount of space created for new objects over the lifetime of the application. This number represents the total amount of memory the program would have consumed had no garbage collection been performed. It is an abstract measure of the total work done by the application.

Number of GC Events  The number of times the garbage collector was invoked during the program run.

Average Ideal Allocation Rate  What the average memory allocation rate for new Java objects would have been had no garbage collection been necessary. It is a theoretical limit of a program's performance if GC time were driven to zero.

Residual Bytes  Heap usage when the program ends.

Time spent in GC  The total amount of wall clock time spent in garbage collection during the program run.

Percentage of Time in GC  The percentage of the total amount of wall clock time spent in garbage collection during the program run. This value displays in red when 5% or more of clock time is spent in garbage collection. When this value shows red, the amount of garbage collection activity should be scrutinized.

Percentage of Time in Full GC  The percentage of the total amount of wall clock time spent doing a full GC during the program run. This value displays in red when 5% or more of clock time is spent in a full garbage collection. When this value shows red, the amount of garbage collection activity should be scrutinized. See also “Comparison of Percentages” color bars.

Average Allocation Rate  The actual average memory allocation rate for new Java objects. See also Average Ideal Allocation Rate.

Precise Data  For rounded values given in MB or GB, mouse over the value to see the measure in precise bytes.

Process is Swapping  Indicates whether or not process swapping is occurring during the measured period. To determine the amount of swap memory occupied when processes are being swapped, click the System Details tab, and locate the swap data in the System and Memory Details section.

Comparison of Percentages  The color bars compare the percentage of time spent in Full GC or in System.gc calls as a percentage of total time spent doing garbage collection. However, if the total time spent in System.gc calls is greater than half the total time spent in Full GC, System.gc percentages will display instead of Full GC percentages.

Understanding the System Details Captured with GC Data

To view the system details for GC data, double-click on the data representation in the main panel. A window will open to display the data. Select the System Details tab.

The following image shows system details collected using the -Xverbosegc option and displayed under the System Details tab.

The data on this tab is a summary of operating system attributes and the JVM options in effect at the time the data collection began. It can be useful to refer to this information when determining adjustments to make in the size of the heap and/or the memory spaces.

Figure 6-3 Summary Panel Showing System Details for a Period of Xverbosegc Data Collection

Summary Panel Showing System Details for a Period of Xverbosegc Data Collection
NOTE: The Number of Localities, Heap Pointer Mode, and UseNUMA fields only display if JDK/JRE 6.0.08 or later is being used.

As with any field whose value is too long for its column width, if the JVM Arguments value shown at the bottom of the panel is extensive and runs beyond its column, you can mouse over the value to display a yellow pop-up box that shows all the JVM arguments. When you mouse away from it, the yellow box disappears. However, if you double click the JVM arguments value, a pop-up box displays and remains until you close it:

Figure 6-4 System Details Tab with JVM Arguments Pop-up Box

System Details Tab with JVM Arguments Pop-up Box