Understanding JVM Runtime Memory and Garbage Collection: A Complete Guide

1.1 Runtime Data Areas

Method Area: shared memory storing class metadata, constants, static variables, JIT‑compiled code, etc. The runtime constant pool is part of the method area.

Before JDK 1.8 the method area was called Permanent Generation; since 1.8 it is Metaspace. Permanent Generation resides inside the JVM heap, while Metaspace uses native memory, avoiding impact on JVM memory. If the method area cannot satisfy a new allocation, an OutOfMemoryError is thrown.

Heap

Shared among threads, stores object instances and arrays. If the heap cannot allocate memory and cannot expand, the JVM throws an OutOfMemoryError. The JVM uses thread‑local allocation buffers (TLAB) to improve allocation efficiency.

Java Virtual Machine Stack

Thread‑private; each method invocation creates a stack frame that stores the local variable table, operand stack, dynamic linking information, and method return data. If the number of stack frames exceeds the limit, a StackOverflowError occurs; if memory expansion fails during dynamic growth, an OutOfMemoryError is thrown.

Native Method Stack

Functions like the JVM stack but is used for native (JNI) methods.

Program Counter (PC) Register

Thread‑private; records the line number of the bytecode currently being executed. It has no defined OutOfMemoryError condition.

2. Object Memory Layout

In HotSpot, an object consists of three parts:

Header : contains hash code, GC generation age, lock flags, biased locking information, and a type pointer (for arrays also stores length).

Instance Data : the actual fields of the object, including those inherited from superclasses.

Padding : filler bytes to ensure the object size is a multiple of 8 bytes.

3. Marking Methods and Process

2.1 Determining if an object is eligible for collection

Two approaches are used:

Reference counting: increments when a reference is created and decrements when it is cleared; a count of zero means the object can be reclaimed, but cycles prevent collection.

Reachability analysis: starts from GC roots and marks all reachable objects; unreachable objects are considered garbage.

2.2 Which objects can be GC Roots?

Objects referenced by local variables in JVM stacks.

Objects referenced by static variables in the method area.

Objects referenced by constants in the method area.

Objects referenced by JNI handles in native method stacks.

2.3 Quickly locating GC Roots – OopMap

HotSpot records object references in an OopMap (Ordinary Object Pointer Map). During GC the VM scans this map to find GC roots. The OopMap is populated after class loading and during JIT compilation.

2.4 Updating OopMap – Safe Points

Safe points are locations where the VM records OopMap updates, such as method calls, loop back‑edges, and exception exits.

2.5 Reachability Analysis Process

Three‑Color Marking

White : objects not yet visited; initially all objects are white (unreachable).

Black : objects that have been visited and whose references have all been scanned; they are considered alive.

Gray : objects that have been visited but still have at least one reference that has not been scanned; they will be processed later.

Inconsistency Issues

During marking, objects may change state, causing white objects to be incorrectly reclaimed. The following diagrams illustrate such scenarios.

If a thread removes a reference from object A to B while the GC root adds a reference to C, the GC may incorrectly collect C.

Solutions

Incremental Update : when a black object acquires a reference to a white object, the white object is recolored gray and rescanned after the concurrent marking phase (used by CMS).

Snapshot‑At‑The‑Beginning (SATB) : records references that disappear during marking; after marking, gray objects are rescanned (used by G1, Shenandoah).

Example

The diagram below shows a scenario where a GC root directly references object C while object A drops its reference to B.

Incremental update records behavior 1, recolors the GC root gray, and prevents B from being reclaimed.

During the next marking phase the GC root and C become black.

SATB records behavior 2; after the marking phase the gray objects are rescanned and marked black.

Consequently, B becomes floating garbage and will be reclaimed in a later GC cycle.

4. Generational Model

4.1 Generational Hypotheses

Weak Generational Hypothesis: most objects die young. Strong Generational Hypothesis: objects that survive many GCs become harder to collect. Inter‑generational Reference Hypothesis: cross‑generation references are rare.

Therefore the heap is divided into Young Generation and Old Generation.

Young Generation holds short‑lived objects; collection is frequent.

Old Generation holds long‑lived objects; collection is less frequent.

4.2 Space Allocation Guarantee

If after a GC the Young Generation cannot accommodate surviving objects, they are promoted directly to the Old Generation (allocation guarantee). Before a Minor GC the VM checks whether the Old Generation has enough contiguous space; if not, a Full GC is triggered.

4.3 Remembered Set and Card Table

The Remembered Set records references from the Old Generation to the Young Generation, allowing Minor GC to scan only the relevant portions. A Card Table is a coarse‑grained bitmap where each entry (card) represents a memory region; a card is marked dirty (value 1) when it contains a cross‑generation reference.

5. Garbage Collection Algorithms

5.1 Mark‑Sweep

Marks all reachable objects, then sweeps away the unmarked ones. This algorithm can cause memory fragmentation.

5.2 Mark‑Copy

Divides the heap into two equal halves; live objects are copied to the other half, and the original half is cleared. This avoids fragmentation but requires twice the memory.

Optimized with Eden and Survivor spaces (ratio 8:1:1). Only Eden and one Survivor space are active at a time; after marking, live objects are copied to the other Survivor space, and objects that age enough are promoted to the Old Generation.

5.3 Mark‑Compact

Marks reachable objects and then compacts them toward one end of the heap, eliminating fragmentation without needing extra space.

Typically used for the Old Generation where copying would be inefficient.

This article introduced the fundamentals of JVM garbage collection; future articles will dive into specific collectors such as CMS, G1, and ZGC.