Mastering JVM Runtime Data Areas: Memory, GC, TLAB & Escape Analysis Explained

Runtime Data Areas

Memory is a crucial system resource that bridges the CPU and storage, supporting the real‑time operation of operating systems and applications. The JVM memory layout defines how Java memory is requested, allocated, and managed during execution, ensuring efficient and stable operation. Different JVM implementations may vary in how they partition and manage memory.

The following diagram shows the overall JVM architecture, with the central part representing the runtime data areas defined by the JVM.

Thread‑private: Program Counter, Stack, Native Stack

Thread‑shared: Heap, Off‑heap memory (Metaspace or Permanent Generation, Code Cache)

Heap Memory

Memory Partitioning

For most applications, the Java heap is the largest memory region managed by the JVM and is shared by all threads. Its sole purpose is to store object instances.

To enable efficient garbage collection, the heap is logically divided into three regions (the sole reason for generational division is to optimize GC performance):

Young Generation (Eden and Survivor spaces): holds new objects and those that have not reached a certain age.

Old Generation: holds long‑lived objects; typically larger than the young generation.

Metaspace (formerly Permanent Generation in JDK 8 and earlier): stores class metadata and other structures.

The Java heap can be physically non‑contiguous as long as it appears contiguous logically, similar to disk space. It can be fixed‑size or expandable; mainstream JVMs use -Xmx and -Xms to control size. If the heap cannot expand further, an OutOfMemoryError is thrown.

Young Generation

The young generation is where all new objects are allocated. When it fills up, a Minor GC occurs. The young generation consists of Eden and two Survivor spaces (From/To or S0/S1) with a default ratio of 8:1:1.

Most new objects are placed in Eden.

When Eden is full, Minor GC moves surviving objects to a Survivor space.

Each GC cycle moves survivors between the two Survivor spaces.

Objects that survive multiple cycles are promoted to the old generation based on an age threshold.

Old Generation

The old generation contains objects that have survived many minor GCs. A Major GC runs when the old generation fills up, typically taking longer.

Large objects that require contiguous memory are allocated directly in the old generation to avoid excessive copying between Eden and Survivor spaces.

Metaspace

Both the pre‑JDK 8 Permanent Generation and the post‑JDK 8 Metaspace implement the JVM specification’s method area. Although described as part of the heap logically, it is often referred to as “Non‑Heap” to distinguish it from the Java heap.

Configuring Heap Size and OOM

The heap size is set at JVM startup using -Xmx (maximum heap) and -Xms (initial heap). By default, the initial heap is memory/64 and the maximum heap is memory/4. The following code prints the current heap settings and simulates an OOM scenario:

public static void main(String[] args) {
    long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
    long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;
    System.out.println("-Xms : " + initialMemory + "M");
    System.out.println("-Xmx : " + maxMemory + "M");
    System.out.println("System memory: " + initialMemory * 64 / 1024 + "G");
    System.out.println("System memory: " + maxMemory * 4 / 1024 + "G");
}

Setting -Xmx and -Xms to the same value can improve performance by avoiding heap resizing after each GC.

Object Lifecycle in the Heap

The heap is divided into Young and Old generations.

New objects are allocated in Eden.

When Eden fills, a Minor GC moves surviving objects to Survivor spaces and increments their age.

Objects that survive enough Minor GCs are promoted to the Old generation.

TLAB (Thread‑Local Allocation Buffer)

TLAB further partitions Eden for each thread, providing a private allocation buffer that reduces contention and improves allocation throughput. It is enabled by default in most OpenJDK‑based JVMs. The size of TLAB can be adjusted with -XX:TLABWasteTargetPercent. If allocation in TLAB fails, the JVM falls back to synchronized allocation in Eden.

Escape Analysis

Escape analysis determines whether an object’s reference escapes the method or thread. If an object does not escape, the JIT compiler can apply optimizations such as stack allocation, lock elimination, and scalar replacement, reducing heap pressure and synchronization overhead.

public static StringBuffer createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb; // sb may escape
}

public static String createString(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString(); // no escape
}

When escape analysis confirms no escape, the JVM can perform stack allocation or scalar replacement, eliminating the need for heap allocation and subsequent garbage collection.

Lock Elimination Example

public void keep() {
    Object keeper = new Object();
    synchronized(keeper) {
        System.out.println(keeper);
    }
}

The synchronized block can be removed because keeper does not escape the method, resulting in:

public void keep() {
    Object keeper = new Object();
    System.out.println(keeper);
}

Scalar Replacement Example

private static void alloc() {
    Point point = new Point(1, 2);
    System.out.println("point.x=" + point.x + "; point.y=" + point.y);
}
class Point { private int x; private int y; }

After escape analysis, the JVM replaces the Point object with two scalar ints, producing:

private static void alloc() {
    int x = 1;
    int y = 2;
    System.out.println("point.x=" + x + "; point.y=" + y);
}

These optimizations reduce heap allocations and improve performance, though escape analysis itself incurs analysis overhead.

(Copyright belongs to the original author, removed upon request)