Heap Walking and Allocation Tracking: TLABs and Heap Analysis

Every Java object you create eventually lives on the heap, and understanding how and where those objects get allocated is critical for diagnosing memory issues. The JVM uses Thread-Local Allocation Buffers (TLABs) to make allocation fast and lock-free, but this also makes tracking allocation origins harder. This guide explains how TLABs work, how to use allocation profiling tools without destroying performance, and how to walk the heap graph when you need to find what is keeping your memory hostage.

Introduction

Every Java object you create lives on the heap, but the path it takes from your code to memory is more nuanced than a simple allocation call. The JVM uses Thread-Local Allocation Buffers (TLABs) to make allocation fast and lock-free, but this optimization also hides most allocations from traditional profilers. Understanding how TLABs work, how to track allocations without destroying performance, and how to walk the object graph when things go wrong are essential skills for anyone diagnosing memory issues in production Java applications.

TLABs sit at the intersection of allocation performance and observability. They eliminate allocation contention in multi-threaded applications, but they also make allocation profiling significantly harder because most objects never touch shared data structures during allocation. To actually see where objects are born, you need sampling-based profiling, JFR events, or JVMTI callbacks—each with different trade-offs. Meanwhile, heap walking answers a different question: not where objects are created, but why they are still alive and what is keeping them in memory.

This post covers TLAB mechanics and allocation tracking, then shifts to heap walking when you need to find retention leaks that allocation data cannot explain. You will learn when to reach for allocation profiling versus heap dumps, how to use async-profiler and JFR for production-safe diagnostics, and how to trace GC root chains to find what is keeping your memory hostage. Practical failure scenarios show how TLAB bias, retention leaks, and off-heap memory all masquerade as different problems.

How the JVM Allocates Memory

Before getting into diagnostics, you need to understand how modern JVMs actually put objects on the heap.

The Problem with Concurrent Allocation

In a multi-threaded application, naively allocating objects on a shared heap requires synchronization. If every thread had to grab a lock to allocate memory, allocation would become a serious bottleneck. The JVM solves this with thread-local allocation buffers.

Thread-Local Allocation Buffers (TLABs)

TLABs are pre-allocated regions of Eden space that are assigned to each application thread. When a thread creates a new object, it allocates memory from its TLAB using a simple pointer bump — no locks, no atomic operations, just writing the object into the buffer and advancing a pointer.

graph TB
    subgraph "Heap"
        direction TB
        subgraph "Eden Space"
            T1[TLAB 1<br/>Thread-1]
            T2[TLAB 2<br/>Thread-2]
            T3[TLAB 3<br/>Thread-3]
        end
        subgraph "Survivor Spaces"
            S1[S0]
            S2[S1]
        end
        subgraph "Old Generation"
            OG[Old Gen]
        end
    end

    T1 -->|Fill, GC| S1
    T2 -->|Fill, GC| S1
    T3 -->|Fill, GC| S2
    S1 -->|Aging| OG
    S2 -->|Aging| OG

When a TLAB is exhausted, the thread requests a new one from Eden. This happens without stopping other threads.

What TLABs Mean for Profiling

Because allocation happens inside the TLAB without any shared lock, traditional allocation profilers that instrument every new keyword see only a small fraction of allocations. The actual heap allocation is hidden inside the TLAB bump operation.

To actually see allocation sites, you need either:

1. Sampling-based allocation profiling (Periodically interrupt threads and inspect their stacks)
2. ObjectAllocationInTLAB and ObjectAllocationOutsideTLAB events from JFR
3. VMObjectAlloc callbacks from JVMTI

When to Use Allocation Tracking

Ideal Use Cases

• Finding allocation hotspots: Which code paths create the most objects?
• Memory leak investigation: What objects are accumulating and who allocates them?
• GC tuning: Which generations are receiving the most allocation traffic?
• Off-heap vs on-heap decisions: How much memory goes to specific types?

When Allocation Tracking Misleads

• TLAB bias: Most small, short-lived objects never appear in allocation profiles because they die inside TLABs
• Sampling bias: Statistical sampling may miss rare but expensive allocations
• Survivor confusion: Allocation rate does not equal heap pressure — a churned survivor space still stresses GC

Implementation: Reading TLAB Statistics

import java.lang.management.*;
import javax.management.*;

public class TlabDiagnostics {
    public void dumpTlabStats() {
        List<MemoryPoolMXBean> pools = ManagementFactory.getMemoryPoolMXBeans();
        for (MemoryPoolMXBean pool : pools) {
            // TLAB stats are in the young generation pools
            MemoryUsage usage = pool.getUsage();
            if (usage == null) continue;

            String name = pool.getName();
            System.out.println("Pool: " + name + " used=" + usage.getUsed());
        }
    }

    public void parseAllocationFromJfr(String jfrFile) throws Exception {
        // Use JFR API to analyze allocation events
        System.out.println("Analyzing allocation from " + jfrFile);
        // jfr print --events ObjectAllocationInTLAB,ObjectAllocationOutsideTLAB file.jfr
    }
}

Using async-profiler for Allocation Profiling

async-profiler can show allocation flame graphs with very low overhead:

# Profile allocations, show top 20 allocation sites
./async-profiler.sh alloc -d 60 -f alloc_profile.html \
    -XX:MaxGCPauseMillis=50 \
    <pid>

# Combined CPU + allocation profiling
./async-profiler.sh combined -d 30 -f combined.html <pid>

The alloc mode uses JVMTI’s VMObjectAlloc callback and is suitable for production with overhead around 2-5%.

Heap Walking

Heap walking traverses the entire object graph to find references between objects. This is how tools like Eclipse MAT find theGC roots that keep objects alive.

GC Roots

Objects are kept alive by references from:

• Thread stacks: Local variables and operand stacks
• JNI references: Native code holding Java object references
• Static fields: Class-level object references
• Running threads: The thread object itself
• Classloaders: Classloader objects
• Finalization queue: Objects awaiting finalization

Walking the Heap with JHSDB

# Attach to a process
jhsdb jhsdb --pid <pid>

# Once attached:
# Walk heap from a specific object
jsadebugd <pid> com.sun.tools.jhsdb.ObjectHistogramViewer

Programmatic Heap Walking with JVMTI

#include <jvmti.h>

static jvmtiEnv *jvmti = NULL;

jlong TAG_LEAKED = 1;

void JNICALL
ObjectFree(jvmtiEnv *jvmti_env, jlong tag) {
    // Object being freed - if it had a tag, we know it was alive
}

jvmtiError JNICALL
iterate_heap_callback(jvmtiHeapReferenceKind ref_kind,
                     const jvmtiHeapReferenceInfo* info,
                     jlong klass, void* user_data) {
    // Called for every reference found during heap iteration
    return JVMTI_ITERATION_CONTINUE;
}

void walk_heap(jvmtiEnv *jvmti) {
    jvmtiHeapCallbacks callbacks;
    memset(&callbacks, 0, sizeof(callbacks));
    callbacks.heap_reference_callback = iterate_heap_callback;

    // Walk all reachable objects
    (*jvmti)->IterateOverReachableHeap(jvmti, NULL, &callbacks, NULL);
}

Production Failure Scenarios

Scenario 1: Allocation Rate Mismatch

Symptom: Your profiler shows low allocation rate but GC is constantly running.

Investigation: Most allocations happen inside TLABs. If objects die young (inside the young generation), they never appear in sampling-based allocation profiles because the profiler only sees allocation sites, not heap turnover.

What TLAB hiding looks like: A profiler might show 100MB/s of allocations, but young GC is reclaiming 2GB/s. The difference is short-lived objects that never get sampled.

Fix: Use GC logs to measure actual allocation rate. JFR’s YGCT and YGC events show you the real churn.

Scenario 2: Retention Leak Masked as Allocation Leak

Symptom: Heap grows but allocation profiling shows no obvious culprit.

Investigation: The problem is not how many objects you allocate, but how long they live. A cache with no eviction policy might allocate a modest number of entries but never release them.

Approach: Use MAT or JMap to take a heap dump and find the GC root chain keeping objects alive. Allocation profiling alone cannot find retention leaks.

# Take heap dump
jmap -dump:file=heap.bin <pid>

# Analyze with jhat (basic)
jhat heap.bin

# Or import into Eclipse MAT

Scenario 3: NIO DirectByteBuffer Appearing as Native Memory Leak

Symptom: Native memory (off-heap) grows continuously, heap looks fine.

Investigation: Direct ByteBuffer allocation happens via PlatformAddress outside the Java heap. Use NMT (Native Memory Tracking) to see the breakdown.

# Enable NMT and check
-XX:NativeMemoryTracking=detail
jcmd <pid> VM.native_memory summary

# Track direct ByteBuffer allocations
jcmd <pid> VM.native_memory baseline
# ... run workload ...
jcmd <pid> VM.native_memory detail.diff

What it showed: File channel reads were accumulating DirectByteBuffer objects with 1MB native allocations each, and only 64KB were being freed because of a bug in the cleanup code.

Trade-off Table

Aspect	JFR Allocation Events	async-profiler alloc	JMap Heap Dump	JVMTI Custom
Overhead	1-5%	2-5%	50-200% (stop-the-world)	5-20%
Data captured	TLAB vs non-TLAB	Call stacks	Full graph	Configurable
Production safe	Yes	Yes	No (pause)	Conditional
Shows retention	No	No	Yes	Yes
TLAB visibility	Yes	Partial	Yes	Yes
Setup complexity	Low	Medium	Low	High

Observability Checklist

• Enable JFR ObjectAllocationInTLAB and ObjectAllocationOutsideTLAB for allocation visibility
• Use async-profiler alloc mode for production-safe allocation flame graphs
• Correlate allocation rate with GC logs — mismatch reveals TLAB hiding
• Take heap dumps during or immediately after incidents (use jcmd instead of jmap)
• Track BufferPool and DirectByteBuffer counts via MBean if using NIO
• Use NMT to understand native vs Java heap memory split
• Set allocation sampling thresholds appropriately — too low creates noise, too high misses small allocations
• Track heap occupancy over time with MemoryMXBean to find gradual leaks
• When retention is the issue, heap dumps are unavoidable — plan for the pause

Security Notes

Allocation data can expose sensitive information:

• Allocation call stacks reveal business logic, API endpoints, and data structures
• Heap dumps contain full application state including session data, tokens, and PII
• Allocation profiling data stored in files may be accessible to unauthorized users

Best practices:

• Take heap dumps only in staging or with explicit approval in production
• Store heap dumps in encrypted storage with access controls
• Cleanse sensitive data from allocation logs before sharing
• Restrict access to allocation flame graph outputs
• Use temporary files for profiling data that are deleted after analysis

Common Pitfalls / Anti-Patterns

Pitfall 1: Confusing Allocation Rate with Heap Pressure

Problem: You optimize the top allocation sites, but heap still grows.

Explanation: Allocation profiling shows where objects are created, not how long they live. Reducing allocations that die young in Eden does not reduce old generation pressure. You need to find retention, not allocation.

Fix: Use heap dumps and GC logs together. GC logs show where memory is actually being retained.

Pitfall 2: Sampling Too Coarsely

Problem: Rare allocations that cause OOM never appear in profiles.

Explanation: If you sample 1 in 1000 allocations, objects allocated infrequently but in large batches (e.g., loading a large dataset once) will be invisible.

Fix: When OOM is your problem, do not rely on sampling. Use heap dumps and look at the total size of objects by class.

Pitfall 3: Ignoring DirectByteBuffer Off-Heap Memory

Problem: Java heap looks fine but OS reports the process using far more memory.

Explanation: Direct ByteBuffer and other off-heap allocations do not appear in Java heap metrics.

Fix: Enable NMT (-XX:NativeMemoryTracking=detail) and monitor jcmd <pid> VM.native_memory.

Pitfall 4: Misreading GC Root Chains

Problem: Heap dump analysis shows a massive object as the leak suspect, but it is just a symptom.

Explanation: MAT-style tools show the path keeping the largest object alive. But that object might itself be referenced by something bigger. You need to walk backwards from the GC root, not forwards from the largest object.

Fix: Use “Path toGC Roots” in MAT, selecting “exclude weak refs” to see what is really pinning memory.

Pitfall 5: TLAB Sizes Changing Under Load

Problem: Allocation profile changes dramatically between idle and peak load.

Explanation: TLAB sizes are dynamically computed based on allocation rate and thread count. When load changes, TLAB sizes change, which changes what appears in allocation profiles.

Fix: Run allocation profiling under realistic load to match production conditions.

Quick Recap Checklist

• TLABs make allocation fast and lock-free but hide most allocations from profilers
• Allocation profiles miss short-lived objects that die inside TLABs
• Use JFR ObjectAllocationInTLAB events to see TLAB vs non-TLAB allocation
• async-profiler alloc mode is production-safe for allocation flame graphs
• Retention leaks require heap dumps, not allocation profiling
• NMT (jcmd VM.native_memory) tracks off-heap memory including DirectByteBuffer
• GC logs show actual heap pressure; allocation profiles show where objects originate
• Take heap dumps with jcmd not jmap for more controlled pauses
• Heap dump analysis with MAT requires understanding GC root chains
• Production allocation profiling overhead should stay under 5%

Interview Questions

Further Reading

• async-profiler GitHub - Allocation profiling and flame graphs
• Eclipse MAT Documentation - Memory Analyzer Tool reference
• JEP 425: Virtual Threads (Java 19+) - How TLAB interacts with virtual threads
• HSDB / jhsdb Tutorial - Using the Heap Statistics Debugger
• NMT (Native Memory Tracking) - Tracking off-heap memory with jcmd

Conclusion

The key to effective heap analysis is picking the right tool for the question you are asking. Allocation profiling tells you where objects are born — useful for finding churn hot spots — while heap walking tells you why objects are still alive — essential for finding retention leaks. TLABs keep allocation fast and lock-free but add complexity when profiling. For production diagnostics, use JFR allocation events or async-profiler; for deep retention analysis, plan for heap dumps during maintenance windows and use MAT to trace GC root chains.