What does the "GC Causes" table report?

GC reports all the reasons which triggered the garbage collection like what events caused GCs, how much time was consumed, etc.

The table contains the GC Causes and corresponding counts, average time, maximum time, and total time for that particular cause. The table reports the following data:

1. Allocation failure: Allocation failure happens when there is not enough free space to create new objects in the young generation. Allocation failures trigger young GC.On Linux, a JVM can trigger a GC if the kernel notifies there isn't much memory left via mem_notify.

2. Ergonomics: GC ergonomics tries to grow or shrink the heap to dynamically meet a specified goal such as minimum pause time and/or throughput

3. System.gc( ) calls: It looks like “System.gc()” or “Runtime.getRuntime.gc()” API is explicitly invoked from your application or third libraries used in your application. Explicit System.gc( ) can degenerate GC performance.

4. Metadata GC Threshold: This type of GC event is triggered under two circumstances.    a) Configured metaspace size is too small than the actual requirement.b) There is a classloader leak (very unlikely, but possible)

5. GCLocker initiated GC:  GC is triggered when a JNI critical region is released. A JNI critical region arises when a native code uses the JNI GetPrimitiveArrayCritical() or GetStringCritical() Functions to obtain a reference to an array or string in the java heap. The reference is held until the native code calls the corresponding release function. The time between the get and release is called a JNI critical section, and during that time the Java VM cannot reach a state that allows garbage collection to occur. GC is blocked when any thread is in the JNI critical region. If GC was requested during that period, that GC is invoked after all the threads exit from the JNI Critical region.