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.

Old generation

Where objects that survived several young collections are tenured. It is collected rarely, and collecting it costs more because most of what it holds is alive.

The occupancy of the old generation right after each old collection is the best signal of a leak or of premature promotion. If it keeps climbing, the application retains more and more data (a leak, an unbounded cache). If it jumps in steps, short-lived data is promoted too early, often because the survivor space is too small or the allocation rate is high.

Collectors reclaim the old generation in different ways: Serial and Parallel compact it during a full stop-the-world collection; CMS (removed in JDK 14) swept it concurrently; G1 marks it concurrently and then reclaims it in small steps with mixed collections; ZGC and Shenandoah collect the whole heap concurrently.

Throughput

The share of time the application spends on useful work rather than in GC pauses.

A throughput of 99 percent means one second of pauses per 100 seconds. Throughput-oriented tuning (Parallel, large heaps) accepts longer and rarer pauses. Latency-oriented tuning (ZGC, Shenandoah, G1 with a low pause goal) accepts more frequent, shorter work and spends more CPU in the collector.

GC Doctor computes throughput from the pauses of the selected range. It ignores concurrent work, which consumes CPU without stopping the application, so read it together with the CPU view.