Java GC Causes Distilled
This comprehensive cheatsheet will help you figure out when garbage collection in Java is triggered and what it should affect.
Join the DZone community and get the full member experience.
Join For FreeAs it's quite obvious, every GC collection in Hotspot JVM has a good reason to start. They might vary with respect to the current situation in the system and memory state. They all are known as GC Causes. Here, we will try to highlight and explain all the possible reasons for GC to start in Java 7/8.
GC Causes
The most common source of knowledge about GC events and causes are GC Logs files, which can be enabled with the -Xloggc:/path/to/file JVM flag. Such files consist of verbose trace data, which is very hard to read. In order to see the whole picture about your GC work, you should use GC Log Analyze tools; the good one for such purpose is GCPlot.
Following is a table which describes each possible GC Cause. It is ordered by an occurrence frequency in an average application.
GC Cause |
Description |
Allocation Failure |
Application tried to make a new allocation and failed due to lack of available space in Young generation; hence Minor GC is required. On Linux, the JVM can trigger a GC if the kernel notifies there isn't much memory left via mem_notify. |
GC Locker |
GC is started after all threads leave the JNI Critical region. For more information on JNI, refer to the Java Native Interface documentation website. GC is blocked when any thread is in the JNI Critical region and can start only when all of them outside of it. |
G1 Evacuation Pause |
This is actual only for the G1 collector. It indicates that it is copying live objects from one set of regions (Young and sometimes Young + Tenured, which is called Mixed) to another set of regions. |
G1 Humongous Allocation |
This is actual only for the G1 collector. Humongous is an allocation when its size is greater than 50% of one region size; the object then allocated in special space. Nevertheless, it also causes normal GC collection to get more (possibly continuous also) space for such objects. |
CMS Initial Mark |
Initial mark phase of CMS, for more details, see Phases of CMS. It also triggers Young Space collection. |
System.gc() |
There was a |
Adaptive Size Ergonomics |
Indicates you are using the adaptive heap size policy (ability to change Young and Tenured spaces size at runtime), enabled via the |
Allocation Profiler |
This is actual only for versions of Java before 8 and only when |
Heap Inspection |
GC was triggered by an inspection operation on the heap, most probably by the jmap tool with the |
Heap Dump |
GC was initiated before heap dump is made by some profiling instrument. |
No GC |
Normally, you shouldn't see this reason. It was occurring in older Java versions, in case jstat command was started before any collection occurred. Other case is when jstat checks GC without any GC activity. |
Last Ditch Collection |
When Metaspace (Java 8+) or PermGen (Java 7-) is full and you can't allocate a new object here, JVM first tries to clean it, triggering appropriate collector. If that's not possible, it then tries to expand it. If that doesn't work as well, it triggers Full GC with this cause name. Soft references are being cleaned during it as well. |
Perm Generation Full |
Triggered as a result of an allocation failure in PermGen. Actual for Java versions prior to 8. |
Metadata GC Threshold |
Triggered as a result of an allocation failure in Metaspace. Metaspace is a replacement for PermGen in Java 8+. |
JvmtiEnv ForceGarbageCollection |
Something called the JVM tool interface function ForceGarbageCollection. |
Topics:
gc monitoring,
jvm,
java,
garbage collection,
tutorial
Published at DZone with permission of Artem Dmitriev. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments