Heap

1Concept / Definition

The heap is the JVM runtime data area from which memory for all class instances and arrays is allocated (JVMS §2.5.3). It is created at JVM startup, shared by all threads of the process, and managed by the garbage collector, which reclaims objects that are no longer reachable. The heap has an initial size, may grow to a configurable maximum, and throws OutOfMemoryError: Java heap space when an allocation cannot be satisfied even after collection.

2Why It Exists

Objects in Java routinely outlive the method call that created them and are shared between threads — a request object handed to a worker thread, an entry placed in a cache, a message queued for later processing. Stack frames are private to one thread and disappear when the method returns, so they cannot hold such objects. A single, collector-managed heap solves both problems and additionally enables:

• Very cheap allocation — contiguous free space allows bump-pointer allocation.
• Compaction — the collector can move objects to eliminate fragmentation, because programs only hold references, never raw addresses.
• Memory safety — no dangling pointers or double frees; memory is reclaimed only when unreachable.

3Core Concepts

Purpose

What lives in the heap

• Every object created with new, including records, enums' constants, lambdas' captured-state objects and boxed primitives.
• Every array, primitive or reference.
• In HotSpot: java.lang.Class mirror objects (which hold static field values), interned strings (the string table references heap strings), and objects created by the JVM itself (exceptions, reflection data).

What does not

• Local variables and operand values — in thread stacks (1.2).
• Class metadata (method bytecode, vtables, constant pools) — in Metaspace (1.5).
• JIT-compiled code — in the code cache.
• Direct buffers' contents and other native allocations — off-heap (1.6).

The heap as an object graph

Objects reference each other, forming a directed graph whose entry points are GC roots: stack slots, static fields, JNI handles and others (3.3). The collector keeps every object reachable from a root and treats the rest as garbage. The heap's steady-state occupancy after collection — the live set — is the most important number for sizing.

Allocation

Fast path

Almost all allocations are performed by bump-pointer allocation inside a Thread-Local Allocation Buffer (TLAB) — a chunk of the young generation (Eden) owned by one thread. Allocation is: read top, add the object size, compare with end, store the new top, write the header. JIT-compiled code inlines these few instructions; no lock or atomic operation is involved.

Slow paths

1. TLAB refill — the TLAB is exhausted; the thread takes a new TLAB from Eden with an atomic compare-and-swap on the shared Eden pointer.
2. Allocation outside TLAB — the object is larger than the remaining TLAB space or a waste threshold; it is allocated directly in Eden.
3. Large objects — G1 allocates objects ≥ half a region as humongous regions; ZGC uses large pages; Parallel may allocate directly in old space.
4. GC — when Eden cannot supply space, a young collection runs and the allocation is retried; after a full GC without success, OutOfMemoryError is thrown.

Allocation avoided

C2's escape analysis can prove that an object never escapes a compiled method and replace it with scalar values in registers (scalar replacement). Such objects never touch the heap. This is why short-lived helper objects in hot code are often free (3.1).

Shared heap

Visibility and safety

Because the heap is shared, any object can be reached from several threads. The Java Memory Model defines when writes made by one thread become visible to another (happens-before via synchronized, volatile, final fields, concurrent collections). Sharing is the source of data races; immutable objects and thread confinement are the standard mitigations (Book 2 concurrency volume).

Contention-free allocation

TLABs make allocation contention-free despite sharing: each thread allocates privately and only coordinates when fetching a new TLAB.

Internal organisation depends on the collector

Sizing

Reserved, committed, used

• Reserved — virtual address space set aside for the maximum heap at startup (costs no RAM).
• Committed — the portion backed by memory the OS has granted; grows from the initial size toward the maximum.
• Used — the portion currently occupied by objects (live plus not-yet-collected garbage).

Setting the size

Growth and shrinking

With -Xms below -Xmx, collectors expand the committed heap when GC time is high relative to application time (GCTimeRatio) and may shrink it when free space exceeds MaxHeapFreeRatio. Resizing costs GC work and makes memory usage variable; services in containers usually fix the size.

Compressed oops

On 64-bit JVMs with a maximum heap below about 32 GB, references are stored as 32-bit compressed oops: offsets divided by the 8-byte object alignment. This saves roughly a third of heap in pointer-heavy data. Crossing the threshold switches to 64-bit references, so a 34 GB heap can hold less data than a 31 GB heap.

4How It Works Internally

• At startup HotSpot reserves one contiguous virtual address range for -Xmx (plus alignment) and commits the initial size.
• The collector partitions the range into its structures and maintains side data in native memory: card table (1 byte per 512 heap bytes), mark bitmaps, remembered sets, region tables. These appear under 'GC' in Native Memory Tracking and scale with heap size.
• Allocation state (TLAB top/end) lives in each thread's JVM structure; Eden's shared top pointer is updated with atomic operations.
• The heap is part of the process's resident memory only for committed and touched pages — AlwaysPreTouch makes all committed pages resident immediately.

5APIs / Features / Syntax

# What did the JVM choose? (container-aware)
$ java -XX:MaxRAMPercentage=75 -XX:+PrintFlagsFinal -version | grep -E " MaxHeapSize| InitialHeapSize| UseCompressedOops"
   size_t InitialHeapSize   = 134217728     {product} {ergonomic}
   size_t MaxHeapSize       = 3221225472    {product} {command line}
     bool UseCompressedOops = true          {product lp64_product} {ergonomic}

# Live process
$ jcmd <pid> GC.heap_info
$ jcmd <pid> VM.flags | tr ' ' '\n' | grep -E "HeapSize|RAMPercentage"
$ jstat -gc <pid> 1s  # capacity (C) and usage (U) per space every second

MemoryMXBean mem = ManagementFactory.getMemoryMXBean();
MemoryUsage heap = mem.getHeapMemoryUsage();  // init, used, committed, max
log.info("heap used={} MB committed={} MB max={} MB",
         heap.getUsed() >> 20, heap.getCommitted() >> 20, heap.getMax() >> 20);

for (MemoryPoolMXBean p : ManagementFactory.getMemoryPoolMXBeans()) {
    if (p.getType() == MemoryType.HEAP) {
        // usage right after the last GC → live-set indicator
        MemoryUsage afterGc = p.getCollectionUsage();
        log.info("{} after last GC: {} MB", p.getName(), afterGc == null ? -1 : afterGc.getUsed() >> 20);
    }
}

6Practical Examples

Sizing scenarios

Deriving heap size from the live set

# 1. Load test at peak traffic with GC logging
# 2. Extract old-generation occupancy after mixed/full GCs (live set)
$ grep -E "Pause Young \(Mixed\)|Pause Full" gc.log | tail -5
[..] GC(812) Pause Young (Mixed) (G1 Evacuation Pause) 2890M->1210M(4096M) 38.2ms
# live set ≈ 1.1–1.2 GB → heap 2.5–4 GB (2–3.5×) → container ≈ heap / 0.75

7Common Problems & Mistakes

8Performance & Production Considerations

• Allocation rate (MB/s) drives young-GC frequency; heap size only changes how often, not how much work per byte allocated.
• Live set determines old-generation work; heap headroom over it determines how comfortably the collector operates.
• Heap dumps on OOM need disk space equal to used heap; plan persistent volumes.
• Monitoring: heap after GC (trend), committed heap, allocation rate, and container RSS versus limit on one dashboard.
• Page faults: first-touch of heap pages costs latency; AlwaysPreTouch moves this to startup.

9Architecture & Design Considerations

Heap sizing is capacity planning. It interacts with deployment topology and data design:

• Many small instances — lower pause impact and blast radius, but fixed per-JVM overhead (Metaspace, code cache, threads) repeats in every instance.
• Few large instances — more efficient memory use, but larger live sets demand low-latency collectors (ZGC) and longer restarts.
• In-process state (caches, sessions, large buffers) must be justified against its heap and GC cost; external caches or streaming often scale better.

10Interview Questions & Answers