JVM Heap Memory: Young Gen, Old Gen, Metaspace, and Object Headers

If you have ever stared at a OutOfMemoryError: Heap Space stack trace and had no idea where to start, you are not alone. The JVM heap looks simple from the outside - just memory for objects - but dig a little deeper and you will find a carefully engineered layout designed to make garbage collection faster and more predictable. This post walks through how the heap is actually organized, what Metaspace is doing in native memory, and how object headers work at the bit level.

Introduction

The JVM heap is the managed memory space where every Java object lives, yet its internal organization is something most developers never think about until things go wrong. The heap is split into generations—Young Generation for short-lived objects and Old Generation for long-lived survivors—each with different garbage collection strategies and performance characteristics. Metaspace lives separately in native memory, storing class metadata that many developers confuse with heap memory when they see an OutOfMemoryError: Metaspace. Understanding this layout is not academic: it directly explains why OutOfMemoryError: Heap Space behaves differently from OutOfMemoryError: Metaspace, why minor GC reclaims most objects while major GC takes longer, and why tuning SurvivorRatio changes application performance in ways that seem counterintuitive.

Object headers are the hidden metadata bolted onto every object—typically 12 bytes on a 64-bit JVM with Compressed OOPs. The mark word stores hash codes, age, and lock state; the klass pointer points to class metadata in Metaspace. These internals matter when you are staring at a heap dump, trying to understand why a 17-byte object actually consumes 24 bytes, or when the JVM is spending unexpected CPU time on GC betweensafepoint operations.

This post walks through heap organization in detail: how objects flow from Eden to Survivor spaces to Old Generation, what actually lives in Metaspace, and how object headers work at the bit level. You will learn to read GC logs in context of the heap layout, size heaps appropriately for your workload, and understand what the JVM is actually doing when it complains about memory.

When to Use This Knowledge

Use when:

• Diagnosing OutOfMemoryError: Heap Space errors
• Tuning garbage collector settings for specific workloads
• Analyzing memory dumps (heap dumps, hprof files)
• Optimizing applications with large object graphs or high allocation rates
• Choosing between different GC algorithms based on heap behavior

Do not use when:

• Writing simple applications with predictable memory usage
• Using managed languages/platforms that abstract away memory details
• Debugging issues unrelated to memory (e.g., CPU bottlenecks)

When NOT to Use This Knowledge

If you are working on short-lived applications with predictable allocation patterns, the JVM defaults handle memory management fine. Tuning SurvivorRatio and tenuring thresholds for a batch job that runs once daily and exits is premature optimization that adds complexity without measurable benefit.

Most applications never need custom heap tuning. Modern GC collectors like G1 and ZGC self-tune effectively for most workloads. If you are not hitting memory errors in production, the default heap settings are probably fine.

In managed environments like Kubernetes, or when using a platform-as-a-service provider that abstracts memory configuration, deep heap knowledge has limited practical value. Focus on application-level concerns like algorithm efficiency and avoiding unnecessary allocations instead. For continued learning on JVM tuning, explore the Advanced Java & JVM Internals roadmap.

JVM Heap Memory Architecture

The heap is split into a few distinct regions, each handling a different phase of an object’s life.

graph TB
    subgraph JVMHeap["JVM Heap Memory"]
        subgraph YoungGen["Young Generation"]
            subgraph Eden["Eden Space"]
                E["Objects allocated here"]
            end
            subgraph SurvivorS["Survivor Space S0"]
                S0["Survivors after minor GC"]
            end
            subgraph SurvivorS1["Survivor Space S1"]
                S1["Survivors after minor GC"]
            end
        end
        subgraph OldGen["Old Generation"]
            OG["Long-lived objects promoted from Young Gen"]
        end
    end
    subgraph NativeMemory["Native Memory"]
        MS["Metaspace - Class Metadata"]
        CCS["Compressed Class Space"]
        TH["Thread Stacks"]
        DM["Direct Memory Buffers"]
    end

    E -->|"Minor GC| Aging"| S0
    E -->|"Minor GC| Aging"| S1
    S0 -->|"After 15 GCs"| OG
    S1 -->|"After 15 GCs"| OG

    class E eden
    class S0,S1 survivor
    class OG old
    class MS,CCS,TH,DM native

Young Generation Details

New objects land in the Young Generation. It has three parts:

• Eden Space: Where allocations start. Most objects die here before they ever get promoted anywhere.
• Survivor Spaces (S0 and S1): Two regions that hold objects that survive a minor GC. Objects cycle between S0 and S1, getting older with each pass - this is called “aging.”

Object Allocation Flow

1. New object allocated in Eden space
2. Minor GC runs - live objects are copied to S0 (or S1)
3. Objects in S0 age and are copied to S1 during next minor GC
4. This ping-pong process continues
5. Objects that reach the tenuring threshold (default: 15) are promoted to Old Generation

The tenuring threshold is configurable via -XX:MaxTenuringThreshold=N where N ranges from 1 to 15 (or 65535 with UseAdaptiveSizePolicy).

Old Generation Details

Once objects have aged out in the Survivor spaces, they end up here. The Old Generation (sometimes called Tenured Generation) is where long-lived objects go to retire.

Characteristics:

• Larger than Young Generation, usually 2-3x
• GC runs less often here, but when it does, it takes longer
• Supports different GC algorithms than Young Generation
• Objects here tend to stick around

When objects get promoted:

• They outgrow the Survivor spaces
• They hit the tenuring threshold (default: 15 minor GCs)
• They are large enough to bypass Young Generation entirely (with -XX:PretenureSizeThreshold)

Metaspace vs Heap

Metaspace is not on the heap at all. It lives in native memory, which trips up a lot of people who see OutOfMemoryError: Metaspace and assume they need to bump -Xmx.

graph LR
    subgraph NativeMemory["Native Memory"]
        MS["Metaspace"]
        CCS["Compressed Class Space"]
        TS["Thread Stacks"]
    end

    class MS,CCS,TS native

Metaspace

Metaspace holds:

• Class metadata (class name, modifiers, field info, method signatures)
• Constant pools
• JIT compiled code
• Internal JVM structures

Heap vs Metaspace at a glance:

Aspect	Heap	Metaspace
What lives here	Object instances	Class metadata
Where	Java managed memory	Native memory
GC	Regular heap GC	Own metadata GC
OOM type	Heap Space	Metaspace
Resize	Via -Xmx	Grows by default, capped by OS

Metaspace configuration:

• -XX:MetaspaceSize - Initial size before first GC
• -XX:MaxMetaspaceSize - Maximum (unlimited by default)
• -XX:MinMetaspaceFreeRatio - Minimum free space after GC

Compressed Class Space

64-bit JVMs with Compressed OOPs need a separate space for class metadata that can be compressed. Set with -XX:CompressedClassSpaceSize (default: 1GB).

Object Header Layout

Every object has a header bolted onto the front of it. Most people never think about this until they are staring at a heap dump or using a tool like JOL.

Mark Word (64 bits / 8 bytes on 64-bit JVM)

|-----------------------|--------------|-------------|
|        Hash Code      |    Age       |  Lock State |
|        (25 bits)      |   (4 bits)   |  (2 bits)   |
|------------------------------------------------------|
|                    Metadata                           |
|                    (23 bits)                          |
|------------------------------------------------------|
|                   Object Reference                    |
|                    (64 bits)                          |
|------------------------------------------------------|

The mark word stores:

• Identity hash code (computed on demand)
• Age (minor GCs survived)
• Lock state (unlocked, biased, thin, or fat)
• GC metadata

Klass Pointer (64 bits / 8 bytes on 64-bit JVM with Compressed OOPs)

Points to the class metadata in Metaspace. With Compressed Object Pointers (OOPs), this is 4 bytes (32 bits).

Array Length (32 bits / 4 bytes) - Arrays only

Just the length. Arrays get this extra field; regular objects do not.

Total Object Header Size

JVM Mode	Object Header Size
32-bit JVM	8 bytes (mark) + 4 bytes (klass) = 12 bytes
64-bit JVM	8 bytes (mark) + 8 bytes (klass) = 16 bytes
64-bit with Compressed OOPs	8 bytes (mark) + 4 bytes (klass) = 12 bytes
Array (64-bit with OOPs)	8 + 4 + 4 = 16 bytes

Production Failure Scenarios

These are the issues I see most often in production.

1. Premature Promotion (Promotion Failure)

Symptom: Frequent Full GC events even though Old Generation is not full.

Cause: Large objects in Young Generation that survive minor GC cause immediate promotion due to -XX:PretenureSizeThreshold or Survivor Space exhaustion.

Solution:

# Increase Survivor spaces
-XX:SurvivorRatio=6
-XX:MaxTenuringThreshold=15

# Or increase total Young Generation
-Xmn512m  # Set Young Generation size

2. Metaspace Exhaustion

Symptom: OutOfMemoryError: Metaspace even though your heap has plenty of room.

Cause: Class loader leaks or frameworks that generate many classes at runtime (OSGi, JSP containers, dynamic proxies, CGLIB).

Solution:

# Set Metaspace limit
-XX:MaxMetaspaceSize=256m

# Monitor class loading
jstat -gc 12078 1000

3. Heap Fragmentation

Symptom: OutOfMemoryError: Heap Space but the heap dump shows plenty of free space scattered around.

Cause: Mark-Sweep leaves gaps. When a large object needs contiguous memory, it fails even though total free memory is sufficient.

Solution:

• Use G1 or ZGC with better compaction
• Increase -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio

Trade-off Table

These are the knobs I reach for most often when tuning heap:

Configuration	Default	Benefit	Cost
-Xms / -Xmx	1/64th of RAM	Predictable memory footprint	Wasted if overprovisioned
-Xmn (Young Gen Size)	Dynamic	Control minor GC frequency	May starve Old Gen
-XX:SurvivorRatio	8 (Eden/Survivor)	Tune how long objects age	Too high wastes space
-XX:MaxTenuringThreshold	15	Longer aging delays promotion	Can flood Old Gen if too high
-XX:MetaspaceSize	Platform dependent	Delays first Metaspace GC	Uses more native memory

Implementation Snippets

Checking Heap Usage

import java.lang.management.*;

public class HeapMemoryMonitor {
    public static void main(String[] args) {
        MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
        MemoryUsage heapUsage = memoryBean.getHeapMemoryUsage();
        MemoryUsage nonHeapUsage = memoryBean.getNonHeapMemoryUsage();

        System.out.println("Heap Memory:");
        System.out.printf("  Used: %d MB%n", heapUsage.getUsed() / 1024 / 1024);
        System.out.printf("  Max: %d MB%n", heapUsage.getMax() / 1024 / 1024);
        System.out.printf("  Committed: %d MB%n", heapUsage.getCommitted() / 1024 / 1024);

        System.out.println("Non-Heap Memory (Metaspace):");
        System.out.printf("  Used: %d MB%n", nonHeapUsage.getUsed() / 1024 / 1024);
    }
}

Analyzing Object Header with JOL

import org.openjdk.jol.info.*;
import org.openjdk.jol.vm.*;

public class ObjectHeaderAnalysis {
    public static void main(String[] args) {
        Object obj = new Object();

        ClassLayout layout = ClassLayout.parseInstance(obj);
        System.out.println(layout.toPrintable());
    }
}

Maven dependency:

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.17</version>
</dependency>

Observability Checklist

• Monitor heap with jstat -gc <pid>
• Enable GC logging: -Xlog:gc*
• Track native memory: jcmd <pid> VM.native_memory summary
• Dump the heap when you need to investigate: jmap -dump:file=heap.hprof <pid>
• Watch Metaspace in jstat -gc <pid> output (columns mc and ccs)
• Set up Flight Recorder for allocation profiling
• Look for frequent Full GC in your GC logs
• Check compressed class pointer mode with -XX:+PrintCompressedOopsMode

Security Notes

1. Heap Dumps can contain PII, passwords, tokens - treat them like sensitive data
2. Native Memory Access (Unsafe) lets you read/write heap directly - lock down module access in production
3. Memory Leaks can exhaust a containerized pod - set resource limits
4. Class Structure in heap dumps can reveal implementation details to attackers

Common Pitfalls / Anti-Patterns

Pitfall	What happens	Fix
-Xmx set to container limit	OOMKilled because OS, Metaspace, direct buffers need memory too	Leave headroom
Ignoring Metaspace sizing	Metaspace OOM in production	Set -XX:MaxMetaspaceSize
Using default SurvivorRatio	Poor aging behavior for your workload	Tune based on allocation rate
Forgetting heap is fragmented	Mark-Sweep leaves gaps	Switch to G1 or ZGC
Young gen too small	Minor GC fires constantly	Bump -Xmn or -XX:NewRatio

Quick Recap Checklist

• Heap = Young Generation (Eden + S0 + S1) + Old Generation
• Metaspace lives in native memory, stores class metadata
• Object header = Mark Word + Klass Pointer (+ array length for arrays)
• Compressed OOPs on 64-bit JVM = 12-byte headers instead of 16
• Young gen sizing controls minor GC frequency and promotion rate
• Metaspace grows by default; set -XX:MaxMetaspaceSize if you need a cap
• jstat, GC logs, and heap dumps are your main debugging tools
• Tune -Xms, -Xmx, -Xmn based on your workload

Interview Questions

Further Reading

• Java Platform, Standard Edition Tools Reference - jstat - Official documentation for the jstat monitoring tool
• Java Object Layout (JOL) - OpenJDK tool for analyzing object and header layouts in the JVM
• Understanding GC Pauses in JVM, HotSpot’s G1 Collector - Oracle’s official G1 tuning guide
• Java Memory Management for Real-Time Applications - Whitepaper on JVM memory for latency-sensitive systems

Conclusion

The JVM heap divides into Young Generation (Eden + S0 + S1) for short-lived objects and Old Generation for long-lived survivors. Metaspace lives in native memory and stores class metadata. Object headers consist of a Mark Word, Klass Pointer, and (for arrays) a length field; compressed OOPs reduce header size from 16 to 12 bytes on 64-bit JVMs under 32GB heap. Size heap with -Xms=-Xmx for predictability and tune SurvivorRatio and tenuring threshold based on your allocation rate.