Java GC Causes Distilled


As 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

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 leaving JNI Critical region. For more information on JNI, refer to the Java Native Interface documentation web site. 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 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 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 System.gc() call in the application code. You can start JVM with -XX:+DisableExplicitGC flag to disable such behavior.
Adaptive Size Ergonomics Indicates you are using the adaptive heap size policy (ability to change Young and Tenured spaces size at runtime), enabled via -XX:+UseAdaptiveSizePolicy flag. By default it is enabled in the recent versions of JVM.
Allocation Profiler This is actual only for versions of Java before 8 and only when -Xaprof is set. It triggers just before JVM exits.
Heap Inspection GC was triggered by an inspection operation on the heap, most probably by jmap tool with -histo:live flag set.
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.