How do TLABs and escape analysis make object allocation cheap on the JVM, and what do they imply about pooling plain objects?

## The problem this answers The naive mental model is: `new` calls into a global allocator that must lock a shared heap, so creating many objects is slow and pooling avoids that. On a modern JVM both halves of that model are wrong. Two mechanisms — **TLABs** and **escape analysis** — make allocation cheap and lock-free. ## TLAB: Thread-Local Allocation Buffer The **young generation** (the region of the heap where new objects are born) is logically a big contiguous area. If every thread bumped the same shared allocation pointer, they would contend on it (needing an atomic operation or lock per allocation). To avoid that, the JVM gives each thread a **TLAB**: a private sub-chunk of the young generation reserved just for that thread. Allocating an object inside a TLAB is: 1. Read the thread's current TLAB top pointer. 2. Add the object's size. 3. Check it still fits within the TLAB end. 4. Write the new top pointer and initialize the object header. This is a **pointer bump** — a few instructions, **no locking**, no contention with other threads. When a TLAB fills up, the thread grabs a fresh one (a rare, slightly more expensive operation). The net effect: allocation throughput is enormous and scales with cores because threads don't fight over the allocation pointer. ## Generational collection complements TLABs Most objects die young ("the weak generational hypothesis"). A **minor GC** collects the young generation by copying only the *live* objects out; the dead ones are reclaimed implicitly by reusing the whole region. So the cost of a short-lived object is roughly: cheap to allocate (pointer bump) + free to collect (never copied because it's already dead). This is the foundation of "allocation is cheap" advice. ## Escape analysis **Escape analysis** is an optimization performed by the JIT (Just-In-Time) compiler, which compiles hot bytecode to native code at runtime. The compiler analyzes whether a newly created object can *escape* the scope that created it: - **No escape** — the object never leaves the method (not returned, not stored in a field, not passed somewhere that keeps it). - **Arg/thread escape** — the object is passed out or shared with other threads. If an object provably does **not** escape, the JIT can apply: - **Scalar replacement** — don't allocate the object at all; put its individual fields into CPU registers or stack slots. The heap object simply ceases to exist. - **Stack allocation / lock elision** — related optimizations, including removing synchronization on an object that can't be seen by other threads. When scalar replacement fires, there is literally **zero** heap allocation and **zero** GC work for that object. ## The implication for pooling Pooling plain objects undermines all of this: 1. **It defeats escape analysis.** A pooled object *must* escape — it is stored in the shared pool so other code can borrow it. So you forfeit scalar replacement and force a real heap object. 2. **It reintroduces contention.** A shared pool needs thread-safe borrow/return (locks or CAS), replacing the lock-free TLAB bump with synchronized bookkeeping. 3. **It promotes garbage to old gen.** A pooled object lives long, so it survives several minor GCs and gets *promoted* to the old generation, whose collections are costlier. You've converted cheap young-gen churn into long-lived old-gen pressure. 4. **It adds correctness hazards.** Reset-on-return, double-return, use-after-return, and leaked-never-returned objects are all new bug classes. ## Caveats — where these don't save you - Escape analysis is **not guaranteed**: it only fires when the JIT compiles the method and can prove non-escape. Megamorphic call sites, large methods, or objects that genuinely escape won't benefit. Don't *rely* on it for correctness, only treat it as a reason not to micro-optimize prematurely. - For **genuinely expensive or scarce** resources (threads, connections, large/direct buffers), the creation cost dwarfs all of the above and pooling remains the right call. TLABs and escape analysis change the calculus for *ordinary value objects*, not for resources. ## Takeaway TLAB pointer-bump allocation + generational collection + escape-analysis scalar replacement make ordinary object creation cheap, lock-free, and sometimes literally eliminated. Pooling such objects gives all of that back. Reserve pooling for expensive/scarce resources, and verify with allocation and GC profiling before reaching for it.