Understanding JVM Memory Structure, Garbage Collection Algorithms, and Optimization Strategies

The Java Virtual Machine (JVM) executes Java bytecode and, while not required for everyday coding, is a frequent topic in technical interviews; this article lists common JVM interview questions and provides detailed answers.

JVM Memory Structure

The JVM memory is divided into a thread‑private area (virtual machine stack, native method stack, and program counter) and a shared area (heap and method‑area/metaspace).

Virtual Machine Stack / Native Method Stack

Each method call creates a stack frame stored in the virtual machine stack; a StackOverflowException occurs when the stack cannot accommodate further frames, e.g., with -Xss 1m and a recursive method allocating a 128 KB array, the fifth recursion exceeds the 1 MB stack limit.

Program Counter

The program counter records the current bytecode line number for each thread, enabling thread scheduling via CPU time‑slicing.

Method Area (Metaspace)

The method area stores class metadata, static variables, and constants.

Heap

Objects created with the new keyword reside in the heap, which is the primary focus of garbage collection. The heap is split into the young generation (Eden and Survivor spaces) and the old generation.

When Can an Object Be Reclaimed?

JVM uses two mechanisms: reference counting (an object with a zero count is eligible for collection, but cannot handle cyclic references) and GC Roots (a set of root objects such as stack‑referenced objects, static fields, constants, and JNI references; objects unreachable from any root are collectible).

Common Garbage‑Collection Algorithms

Mark‑Sweep

Marks reachable objects from GC Roots, then sweeps away unmarked ones; fast but can cause memory fragmentation.

Mark‑Compact

After marking, it compacts live objects to eliminate fragmentation; however, moving objects incurs higher overhead.

Copying (Semispace)

Divides the heap into two equal regions; live objects are copied to the opposite region during a collection, leaving the current region empty. This avoids fragmentation but wastes up to 50 % of heap space.

When Does an Object Move to the Old Generation?

Objects start in the young generation and are promoted based on age (default threshold 15 minor GCs, configurable via -XX:MaxTenuringThreshold), dynamic age heuristics (if Survivor occupancy exceeds 50 % of its size, older objects are promoted), or size (objects larger than -XX:PretenureSizeThreshold are allocated directly in the old generation).

Space Allocation Guarantee Strategy

Before a Minor GC, the JVM checks whether the old generation has enough contiguous space for all surviving young‑generation objects; if not, it may trigger a Full GC depending on the HandlePromotionFailure flag.

How to Reduce Full GC

Typical tuning steps for a 4‑core, 8 GB machine include allocating 3 GB heap, splitting the young generation (1.5 GB total, 1228 MB Eden, 153 MB Survivor), setting method‑area size, and configuring stack size. Example JVM options:

-Xms3072m
-Xmx3072m
-XX:PermSize=256m
-XX:MaxPermSize=256m
-XX:HandlePromotionFailure
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=6
-XX:PretenureSizeThreshold=1m

Estimating per‑second memory allocation (e.g., 500 requests × 100 KB ≈ 50 MB) helps predict Minor GC frequency (≈ every 25 seconds for a 1228 MB Eden). Adjusting Survivor size, promoting large objects directly, and lowering the tenuring threshold can prevent frequent Full GCs.