Understanding Automatic Garbage Collection and Generational GC in the JVM

Automatic garbage collection (GC) is a mechanism that identifies objects in heap memory that are still referenced and those that are not, and frees the memory occupied by the latter.

In languages like C, programmers manually allocate and release memory, whereas Java relies on a GC to handle memory reclamation. The GC process typically consists of three steps: marking, sweeping, and compaction.

During the marking phase, the collector traverses the object graph to mark all reachable (referenced) objects, leaving unreferenced objects unmarked. The following diagram illustrates referenced objects in blue and unreferenced ones in orange.

The sweep phase removes the unmarked objects, and the memory allocator retains references to the freed space for future allocations.

Compaction (or compression) then moves the remaining live objects together, reducing fragmentation and simplifying subsequent allocations.

Because scanning the entire heap for every collection is inefficient, modern JVMs use generational GC. Empirical data shows most objects die young, so the heap is divided into generations: Young (including Eden and Survivor spaces), Old, and Permanent (Metaspace).

New objects are allocated in Eden. When Eden fills, a minor GC occurs: live objects are moved to a Survivor space, and unreferenced objects are reclaimed. Successive minor GCs alternate between the two Survivor spaces, aging objects each time. Once an object reaches a certain age threshold, it is promoted to the Old generation.

When Eden fills, a minor GC is triggered, clearing unreferenced objects and moving referenced ones to the first Survivor space.

In the next minor GC, live objects are moved to the second Survivor space (S1), while objects that survived previous cycles increase their age and may eventually be promoted to the Old generation.

Subsequent minor GCs repeat this process, swapping Survivor spaces and continuing to age objects until they are promoted.

The promotion diagram shows that after several minor GCs, objects that reach the age threshold (e.g., 8) are moved from the young generation to the old generation.

Major (or full) GC collects the Old generation, which may involve longer stop‑the‑world pauses, especially depending on the chosen old‑generation collector. The Permanent generation holds class metadata and can also be reclaimed when classes become unused.

The series of diagrams in the original article illustrate the flow of objects through Eden, Survivor spaces, promotion to Old, and eventual reclamation, providing a visual overview of the JVM’s generational garbage‑collection process.