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 Garbage Collection Types Recognized by HPjmeter

Concurrent Mark-Sweep	A 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 Scavenge	Only objects from the young generation are collected using a multi-threaded garbage collector.
Scavenge	Objects from the young generation only are collected using a single thread.
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 GC	Necessary when the old area is expanded on the most recent scavenge. Typically, this happens when `-Xms` and `-Xmx` are not the same.
Perm Full	Full GC necessary because the space reserved for metadata is full.
Train Full	Full GC necessary because intermediate space assigned to collection using the train algorithm is full.
Old Too Full	Full 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 Full	Full 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.gc	The application calls method `System.gc()` to force a full garbage collection.
Heap Dump Triggered GC	A full GC is performed as a result of a signal sent to the JVM to collect a heap dump.
Other Full GC	A full garbage collection of unknown type and cause.

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 -verbosegc option and displayed under the Summary tab. Important aspects of the summary data are defined below the image.

Figure 6-1 Summary Panel Showing Garbage Collection Statistics

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

Peak Utilization. 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. 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.

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

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.

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. Note that the color bars compare the amount of wall clock time spent in full GC to the total time spent for all garbage collection.

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

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

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. 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 detail 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 -verbosegc 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-2 Summary Panel Showing System Details for a Period of Xverbosegc Data Collection

Basic Garbage Collection Concepts

Technical documentation

» Table of Contents

» Glossary

» Index

Key to Garbage Collection Types Recognized by HPjmeter

Understanding the Summary Presentation of GC Data

Understanding the System Details Captured with GC Data