Object Allocation & TLAB

## The shape of the young space Almost every `new` on HotSpot lands in the young part of the heap, conventionally called Eden. Every young collector in current HotSpot moves objects: it copies the small live set elsewhere and leaves the collected space empty. Because of that, free memory in Eden is not a linked list of holes — it is one contiguous range described by a start and an end address. Allocating N bytes is then arithmetic: take the current free pointer, add N, and if the result is still below the end, the object occupies the old pointer's address. This is called bump-the-pointer allocation, and it is a handful of instructions rather than the search-a-free-list work a general allocator such as C's malloc must do. ## Why one shared pointer does not scale If all application threads bumped one shared pointer, the read-modify-write would have to be atomic, typically a compare-and-swap loop. Two costs follow. First, under contention the CAS fails and retries. Second, and worse, the cache line holding the pointer is written by every allocating thread, so it migrates between cores continuously; on a 32-core machine allocating hard, that single line becomes the bottleneck and allocation throughput stops scaling with cores. ## The buffer A TLAB fixes this by partitioning. Each Java thread carves out a slice of Eden for its exclusive use — typically tens to hundreds of kilobytes — and keeps three words in its own thread structure: the buffer start, the current top, and the end. Because only the owner thread ever reads or writes its own top, no atomicity is required at all. The JIT inlines the fast path directly into compiled code: 1. load `top` from the thread structure; 2. add the object's size (known statically for a class, computed for an array); 3. compare with `end`; if it exceeds it, jump to the slow path; 4. store the new `top`; 5. initialize the object header (mark word plus class pointer) and any fields not covered by pre-zeroed memory; 6. return the old `top` as the reference. There is no lock, no CAS, and no memory fence on this path. The claim that JVM allocation is faster than C malloc is about exactly this sequence. ## What still costs something Allocation is cheap, not free. Java requires fields to start at their default values, so the memory must be zeroed; HotSpot either zeroes the whole TLAB when it is handed out or zeroes each object as it is allocated, and either way the cost is proportional to bytes allocated. Header initialization is a couple of stores. And every allocated byte is future work for the collector: bytes allocated per second determine how often the young space fills and therefore how often young collections run. A pleasant side effect of thread-local buffers is locality. Objects allocated close together in time by one thread are contiguous in that thread's buffer, so they tend to share cache lines and are prefetch-friendly, and two threads' fresh objects never share a cache line, which avoids accidental false sharing between unrelated threads. ## When the fast path is not taken Three cases leave the fast path: the object does not fit in the remaining buffer (refill or allocate outside the buffer), the object is large enough that giving it a buffer would be wasteful (allocated directly in the shared young space, or straight into the old generation or a humongous region depending on collector and size), and TLABs being switched off with `-XX:-UseTLAB`, which is a debugging option only — doing it in production collapses allocation onto a synchronized shared path. One invariant matters for correctness: the heap must remain parsable, meaning a collector can walk it object by object. Since a retired buffer usually has unused tail space, the JVM fills that gap with a dummy filler object (typically an int array) so the walk does not run into uninitialized memory.