Understanding JVM Runtime Memory Layout, Garbage Collection Roots, and Algorithms

JVM Runtime Memory and Garbage Collection Overview

Java's simple syntax lets developers write functional code without deep JVM knowledge, but a solid understanding of the JVM is essential for performance optimization and avoiding memory issues.

1.1 Runtime Data Areas

The JVM divides memory into several regions: the Method Area (stores class metadata, constants, static variables, and JIT‑compiled code; pre‑Java 8 it was called the Permanent Generation, later replaced by Metaspace), the Heap (shared among threads, holds object instances and arrays, with allocation buffers to improve efficiency), the Java Stack (thread‑private, holds stack frames for method execution), the Native Stack (stores native method frames), and the Program Counter (thread‑private, records the current bytecode line). OutOfMemoryError is thrown when any region cannot satisfy allocation requests.

1.2 Object Memory Layout

In HotSpot, each object consists of three parts: the object header (contains hash code, GC generation age, lock status, type pointer, and for arrays the length), the instance data (fields of the object and its superclasses), and padding to align the object size to an 8‑byte boundary.

2 Marking and Reachability

Two approaches determine whether an object can be reclaimed: reference‑counting (increments on reference, decrements on release; fails with cyclic references) and the reachability algorithm, which starts from GC Roots and marks all reachable objects. GC Roots include local variables on the Java stack, static variables in the Method Area, constants in the runtime constant pool, and JNI references from the native stack.

2.1 GC Roots

GC Roots are the starting points for reachability analysis and consist of: Local variables on the Java stack referencing objects Static variables in the Method Area Constants in the runtime constant pool JNI references in the native stack

2.2 Marking Process

The three‑color marking algorithm classifies objects as white (unvisited), gray (visited but its references not fully scanned), or black (fully visited). Inconsistencies can arise when object references change during marking, potentially causing reachable objects to be incorrectly reclaimed.

2.3 Solutions

Two common remedies are incremental updates (recording changes to gray objects and rescanning after the marking phase) and the Snapshot‑At‑The‑Beginning (SATB) approach, which logs objects whose references change during marking; CMS uses incremental updates, while G1 and Shenandoah rely on SATB.

3 Generational Model

Based on empirical observations, most objects die young (Weak Generational Hypothesis) while objects that survive many collections become harder to collect (Strong Generational Hypothesis). Consequently, the heap is split into a Young Generation (frequent, low‑pause collections) and an Old Generation (infrequent, high‑pause collections). Allocation guarantees ensure that before a Minor GC, the Old Generation has enough contiguous space to accommodate objects promoted from the Young Generation.

3.3 Remembered Set and Card Table

A Remembered Set records references from the Old Generation to the Young Generation, reducing the scanning scope during Minor GCs. Implementations vary in granularity; the Card Table is a coarse‑grained byte array where each entry represents a memory region (a "card"); a value of 1 indicates a cross‑generation reference.

4 Garbage Collection Algorithms

Mark‑Sweep : Marks reachable objects, then sweeps away unmarked ones, leaving fragmented free space. Mark‑Copy : Divides memory into two halves; live objects are copied to the other half, and the original half is cleared, eliminating fragmentation but requiring twice the memory. The Eden/Survivor scheme optimizes this by using three spaces (Eden, two Survivor spaces) with a typical 8:1:1 size ratio. Mark‑Compact : After marking, live objects are compacted toward one end of the heap, eliminating fragmentation without the extra memory overhead of copying. In practice, young‑generation collections often use copying, while old‑generation collections prefer Mark‑Sweep or Mark‑Compact, switching to compaction when fragmentation becomes severe. Conclusion: This article introduced fundamental concepts of JVM garbage collection, including memory regions, object layout, GC roots, marking strategies, generational hypotheses, remembered sets, and the main collection algorithms. Future articles will dive deeper into specific collectors such as CMS, G1, and ZGC.