an arena / region (bump) allocator

Imagine a long roll of receipt paper and a pen. Every time you need to write something down, you just write at the current position and slide the pen forward by however much you wrote. You never go back to erase a single entry — there is no eraser. When the whole job is done, you throw away the entire roll at once. That is an arena allocator: you allocate by simply moving a pointer forward (a bump), and you free everything together in one stroke. There is no per-object free.

Mechanically it is almost laughably simple. The arena holds one big buffer and a single pointer, often called the bump pointer, marking the boundary between used and free. To allocate n bytes you round n up for alignment, check that there is room, return the current pointer, and advance it by n. That is it — allocation is a handful of instructions with no searching, no free list, no headers. The catch is that there is no individual free: free(p) does nothing meaningful, because nothing tracks where p ended or whether anyone after it is still live. Reclamation happens only by resetting the whole arena: set the bump pointer back to the start (or release the buffer). At that instant every object in the arena is gone at once.

This is a perfect fit for phase-based work where many objects share one lifetime: parsing a file (allocate all the AST nodes, process them, free the arena), serving one web request (allocate everything for that request, drop it all when the response is sent), or one frame of a game. It is blazing fast and has essentially zero per-object bookkeeping overhead, and it sidesteps fragmentation and use-after-free of individual objects entirely. The honest limit: it is useless when objects have independent, interleaved lifetimes — if some objects in the arena must outlive others, you cannot reclaim memory until the very last one is done, so a long-lived object pins the whole region.