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-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. |
| Scavenge during CMS | Collection 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 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. |
| JVMTI force GC | A garbage collection is performed as a
result of invoking the ForceGarbageCollection function
of JVMTI. |
| Other Full GC | A full garbage
collection of unknown type and cause. |
| CMS First STW | Mark 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 STW | Mark 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 (.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 -verbosegc option and displayed under the Summary tab. Important aspects of the summary data are defined below the
image.
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. 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”.
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.
Printable version
