Each time a garbage collection event occurs a reason code is emitted along with other data related to the event. Understanding the reason for garbage collection may be useful in planning a strategy for reducing garbage collection overhead.
A basic principle behind the design of the garbage collector is that objects tend to be either short-lived or persistent during the lifetime of an application. By separating the persistent objects from the others, the garbage collector avoids examining all objects each time by considering just the recently created ones. An object ages each time it survives a garbage collection event. It becomes designated as old after surviving a certain number of garbage collection events, at which point it is moved from the young to the old area of the heap. A scavenge garbage collection event is one during which only short-lived unused objects are collected from the young heap area. In contrast, full garbage collection involves examination of all objects. Typically, scavenges are much faster than full garbage collections.
HPjtune may indicate garbage collection types both numerically and by name. Following is a brief description of the various types you may see.
EVENT | DESCRIPTION |
(0) Concurrent Mark-Sweep | A background thread performed (old area) garbage collection mostly without pausing the application. |
(1) Parallel Scavenge | Only objects from the young generation were collected, using multi-threaded garbage collector. |
(2) Scavenge | Only objects from the young generation were collected (single-threaded collection). |
(3) Incomplete Concurrent Mark-Sweep | A background thread was performing (old area) garbage collection, but could not complete its task because the JVM determined that a full GC was needed. |
(4) Old Expanded | Full GC was necessary because old area expanded on last scavenge. Happens when -Xms and -Xmx are not the same. |
(5) Perm Full | Full GC was necessary because the space reserved for "meta data" (objects needed by the Java interpreter and for the reflection) was full. |
(6) Train Full | Reserved for JVM developers. |
(7) Old Too Full | Full GC was necessary because the old area was too full for a scavenge collection, determined without the need to analyze the heap as with (9) Old Full. |
(8) Old Full | Full GC was performed because the garbage collector determined there was likely not enough space for old objects for a scavenge to succeed. |
(9) Full GC A Lot | Reserved for JVM developers. |
(10) System.gc | The application called the method System.gc(), which forced a full garbage collection. |
(11) Other Full GC | A full garbage collection of unknown type and cause. |