Concurrent mode failure (CMS)

CMS only. The old generation filled up before the concurrent cycle finished, so the JVM stopped the application and ran a full compacting collection.

CMS had to start its concurrent cycle early enough to finish before promotion filled the old generation (it starts at the occupancy set by -XX:CMSInitiatingOccupancyFraction, adapted by default). If promotion was faster than the cycle, or if fragmentation left no free block big enough for a promoted object, the JVM logged concurrent mode failure and fell back to a serial full collection, with pauses of several seconds on large heaps.

CMS was deprecated in JDK 9 and removed in JDK 14, so this message only appears in older logs. Lowering the initiation threshold, enlarging the heap or switching to G1 are the usual remedies. Modern collectors have the same failure under other names: evacuation failure (G1), degenerated GC (Shenandoah), allocation stall (ZGC).

Full GC

A stop-the-world collection of the entire heap: mark, then compact. The slowest collection; in a healthy application it is rare or absent.

Typical triggers: no room to promote or allocate after a young collection (Allocation Failure), an explicit System.gc() call, the metaspace threshold, a heap inspection or heap dump request, a concurrent collector that fell behind. The cost grows with the live data, since all of it must be marked and moved: seconds on a multi-gigabyte heap.

Serial and Parallel collect their old generation with a full collection by design. G1 uses a parallel full collection since JDK 10, but it remains a last resort. The sign of a problem is frequent full collections that reclaim little: the live data set is close to the heap size, and the application either leaks memory or is under-provisioned. Read the cause in the log line, Pause Full (cause), then the heap after the collection. GC Doctor lists every full GC with its cause and its heap before and after.