JVM Core Concepts: Memory Areas, Class Loading, Object Creation, and Garbage Collection

Hello everyone, I am GanHuoXuan. Today I’m back with more technical content about the JVM.

What is the main purpose of the JVM?

JVM stands for Java Virtual Machine. It abstracts away OS‑specific details so that Java programs compile to bytecode that can run on any platform supporting a JVM.

Describe the Java memory areas

The JVM divides the memory it manages into several regions, some thread‑private and some shared, collectively called the runtime data area:

Virtual Machine Stack : thread‑private stack that stores local variables and a stack frame for each method invocation.

Native Method Stack : thread‑private stack for methods declared with the native keyword.

Program Counter : thread‑private register that holds the address of the next instruction to execute.

Method Area : shared area that stores class metadata, constants, static variables, and JIT‑compiled code.

Heap : shared area where all object instances are allocated. Since JDK 1.7 the string constant pool resides in the heap.

Runtime Constant Pool : part of the method area that holds constants and symbolic references; it can be populated at runtime (e.g., via String.intern() ).

The heap is further divided into Eden, Survivor (0 and 1), and Old generations, with typical size ratios of 8:1:1.

Describe the Java class‑loading mechanism

The JVM loads class data from .class files into memory and performs verification, preparation, and initialization, forming a Java type ready for execution.

The loading phase includes three steps:

Obtain the binary byte stream of a class by its fully qualified name.

Convert the byte stream into the internal data structures stored in the method area.

Create a Class object that serves as an entry point to the data structure.

Class loading can be performed by the built‑in bootstrap class loader or by custom class loaders defined by the programmer.

Verification

Verification ensures that the class file conforms to the JVM specification, checking file format, metadata, bytecode, and symbolic references.

Preparation

During preparation, memory for static variables is allocated in the method area and default values are set.

Resolution

Resolution replaces symbolic references in the constant pool with direct references.

Initialization

Initialization runs the class’s <clinit> method and any static initializers.

How are objects created in the JVM?

When the JVM encounters a new bytecode, it checks that the class has been loaded, linked, and initialized, then allocates memory (often using TLAB), zero‑initializes the memory, and sets up the object header (MarkWord, Klass pointer, etc.). After allocation, the constructor ( <init> ) is executed.

Memory allocation strategies

If the heap is contiguous, the JVM uses the "bump‑the‑pointer" (pointer collision) technique; otherwise it uses a free‑list to find a suitable block.

Object memory layout

In HotSpot, an object consists of three parts:

Object Header (MarkWord, Klass Pointer, and array length for arrays).

Instance Data (the actual fields of the object).

Padding to align the object size to an 8‑byte boundary.

The MarkWord encodes hash code, age, lock state (no‑lock, biased, lightweight, heavyweight, GC mark), and other bits.

Object access methods

Objects can be accessed via handles (indirect pointers stored in a handle pool) or direct pointers (the reference points straight to the object’s data). Handles simplify object relocation; direct pointers are faster.

How does the JVM determine that an object is dead?

Two main techniques are used:

Reference‑counting (not used by HotSpot due to cyclic‑reference problems).

Reachability analysis from GC Roots (stack variables, static fields, JNI references, internal JVM references, synchronized monitors, etc.).

When is a class considered unused?

All its instances have been reclaimed.

The class loader that loaded it has been reclaimed.

The Class object is no longer reachable.

JVM generational collection theory

The JVM assumes most objects die young (strong generational hypothesis) and that objects that survive many collections become harder to collect (weak generational hypothesis). This leads to a division of the heap into Young and Old generations, with a Remembered Set tracking cross‑generation references.

Garbage‑collection algorithms

Mark‑Sweep

Marks reachable objects, then sweeps away the unmarked ones. It can cause memory fragmentation and variable pause times.

Mark‑Copy

Divides the heap into two equal halves; live objects are copied from one half to the other, eliminating fragmentation but using only half the memory.

Mark‑Compact

After marking, live objects are moved to one end of the heap, then the free space is reclaimed as a contiguous block.

Garbage‑collector implementations in HotSpot

Serial

Single‑threaded, uses copy collection for the young generation, and stops all application threads (STW).

ParNew

Multithreaded version of Serial for the young generation.

Parallel Scavenge

Focuses on maximizing throughput; also a copy collector for the young generation.

Serial Old

Single‑threaded mark‑compact collector for the old generation.

Parallel Old

Multithreaded mark‑compact collector for the old generation.

CMS (Concurrent Mark‑Sweep)

Targets low pause times by performing most work concurrently; suffers from “floating garbage” and can cause fragmentation.

G1 (Garbage‑First)

Divides the heap into regions; collects a set of regions (Collection Set) each cycle, aiming for predictable pause times while maintaining high throughput.

Common JVM commands

jps : Lists running JVM processes.

jstat : Shows JVM statistics (class loading, memory, GC, JIT, etc.).

jinfo : Displays or modifies JVM configuration parameters.

jmap : Generates heap dumps for memory analysis.

jhat : Analyzes heap dump files.

jstack : Prints thread stack traces.

Parent‑delegation class‑loading model

The JVM uses three built‑in class loaders (Bootstrap, Extension, Application) arranged in a parent‑delegation hierarchy. Custom class loaders can break this model, and mechanisms such as the thread‑context class loader, SPI, OSGi, and hot‑deployment have introduced three “breaks” to the original delegation model.

Typical JVM tuning parameters

-Xms, -Xmx: initial and maximum heap size.

-Xmn: size of the young generation.

-XX:+PrintGCDetails: prints detailed GC logs.

-XX:+UseSerialGC, -XX:+UseParallelGC, -XX:+UseConcMarkSweepGC, etc.: select different garbage collectors.

-XX:NewRatio, -XX:SurvivorRatio: control generation size ratios.

-XX:MetaspaceSize, -XX:MaxMetaspaceSize: configure metaspace.

End of article – thank you for reading!