Mastering JVM: Memory Areas, GC, and Class Loading Explained

Java Runtime Data Areas

The JVM divides the memory it manages into several distinct runtime data regions, each with its own purpose and lifecycle. These include the program counter, JVM stacks, native method stacks, method area, heap, and others.

1. Program Counter (PC) : Points to the next bytecode instruction to execute; it is thread‑private.

2. JVM Stack : Stores frames for each method invocation, containing local variables, operand stack, dynamic linking information, and return values.

3. Native Method Stack : Holds memory for native (C/C++) method calls; also thread‑private.

4. Method Area : Stores loaded class metadata, constants, static variables, and JIT‑compiled code; shared among threads. It includes the runtime constant pool.

5. Heap : The main area for Java object allocation; shared by all threads and managed by the garbage collector.

Java Memory Model (JMM)

JMM defines how threads interact through shared memory. All variables reside in main memory, while each thread has its own working memory (a copy of variables). Operations on variables must occur in the working memory, and visibility between threads is achieved by synchronizing with main memory.

Key actions include lock, unlock, read, load, use, assign, store, and write. Proper ordering guarantees visibility and ordering semantics.

Heap Memory Layout

The heap is divided into Young Generation (Eden + Survivor spaces) and Old Generation. In JDK 8, the Permanent Generation was replaced by Metaspace, which resides in native memory.

Young Generation uses a copying algorithm; objects that survive are moved to Survivor spaces and eventually promoted to the Old Generation. Old Generation typically uses a mark‑compact algorithm.

Garbage Collection (GC)

GC determines object reachability using a set of GC Roots (e.g., thread stacks, static fields, native references). Objects unreachable from any root are eligible for collection after a two‑phase process: reachability analysis and finalization handling.

Common GC algorithms include:

Mark‑Sweep

Copying (used for the Young Generation)

Mark‑Compact (used for the Old Generation)

Generational collection (combining the above)

GC pauses occur because reachability analysis must see a consistent object graph; therefore, all Java threads are stopped at safe points.

HotSpot VM Details

Object Creation : New objects are allocated in the heap, optionally using thread‑local allocation buffers (TLAB) for reduced contention. Memory is zero‑filled, and object headers store metadata such as hash code, GC age, and a pointer to class metadata.

Object Access : References may be handles (indirect pointers) or direct pointers. Handles simplify GC movement; direct pointers reduce indirection overhead.

GC Implementation : HotSpot uses OopMaps to locate GC roots and defines safe points where threads can be paused. Interrupts can be preemptive or cooperative.

CMS Collector : A low‑pause collector based on mark‑sweep, performing initial marking, concurrent marking, remarking, and concurrent sweeping. It reduces pause times but may suffer from fragmentation and “floating garbage”.

JVM Performance Tuning

Typical tuning flags include: -Xmn – set young generation size -XX:MaxTenuringThreshold – control promotion age -Xms and -Xmx – set initial and maximum heap size (often set equal for a fixed heap) -XX:MinHeapFreeRatio / -XX:MaxHeapFreeRatio – control heap expansion/shrinking -XX:+UseParallelGC / -XX:+UseParallelOldGC – enable parallel collectors for throughput -XX:+UseConcMarkSweepGC – enable CMS for low pause times -XX:SurvivorRatio=3 – set Eden to Survivor ratio

Diagnostic tools such as jps, jstack, jmap, jstat, and VisualVM help monitor and troubleshoot JVM behavior.

Class Loading Mechanism

Class loading consists of three phases: Loading (reading binary data), Linking (verification, preparation, and resolution), and Initialization (executing static initializers).

Verification checks class file structure, semantics, bytecode safety, and binary compatibility.

Preparation allocates static fields with default values; resolution replaces symbolic references with direct pointers.

Initialization assigns proper initial values to static fields and runs <clinit> blocks.

The JVM follows the parent‑delegation model: a class loader first delegates to its parent before attempting to load the class itself, enhancing security and preventing duplicate loading.

Three built‑in class loaders exist: Bootstrap (loads core Java classes), Extension (loads from the extensions directory), and System/Application (loads from the classpath). Custom class loaders can be created by extending java.lang.ClassLoader and overriding findClass, enabling loading from unconventional sources or applying decryption.

Classes are actively used when they are instantiated, have static fields accessed, static methods invoked, are reflected upon, subclassed, or designated as the entry point. Passive use does not trigger initialization.

Classes loaded by the built‑in loaders are never unloaded; only classes loaded by user‑defined loaders can be garbage‑collected.

Additional Notes

JDK (Java Development Kit) provides development libraries, while JRE (Java Runtime Environment) supplies the runtime libraries needed to execute Java programs.

Java source files are compiled to bytecode (.class) and then interpreted or JIT‑compiled by the JVM into native machine instructions.