Arenas and pools: reuse storage without reusing stale meaning

A simple bump arena reserves a region and advances a cursor for each allocation, inserting alignment padding as needed. It can reclaim all allocations together by resetting the cursor after every user of those objects has finished. This fits a parser whose temporary syntax nodes all die after one request. It fits poorly when one tiny result must escape and keep an entire large region available. Copying an independent result out before reset may be a better boundary than allowing a reference to escape.

Bulk storage reclamation and resource destruction are different operations. Objects can own files, locks, external buffers, or reference-counted handles that need cleanup even if their containing bytes are cheap to discard. An arena API may track destructors, require explicit cleanup, or restrict the types it stores. Read that contract. Never assume resetting raw storage automatically performs every object's semantic cleanup. Also distinguish returning the cursor to the start from releasing the arena's backing reservation or physical pages to the operating system.

A fixed-size pool divides backing storage into reusable slots and tracks which slots are available. A released slot can later hold a different object, so an old pointer cannot be validated by its address alone. Handle-based designs sometimes attach a generation number to the slot index and compare it on lookup. That helps detect stale handles within the design's assumptions, but finite generation counters can wrap and concurrent reclamation still needs a synchronization argument. A pool's bookkeeping is part of its safety boundary, not merely a performance detail.

Pools can retain a workload's high-water capacity after demand falls. Per-thread caches can multiply this retained capacity, while sharing one pool can introduce contention. Size classes reduce external searching but can waste space inside each slot when object sizes differ. Compare the total retained backing storage, metadata, alignment padding, and actual useful live payload. Reuse can also preserve sensitive bytes unless initialization or clearing handles them appropriately. A faster allocation path is not sufficient evidence that the whole request uses less memory or less CPU.

Before introducing an arena or pool, profile allocation count, lifetime distribution, peak simultaneous demand, and time spent in the existing allocator. A request arena can reduce bookkeeping yet keep dead intermediates until request completion, increasing peak live backing storage relative to earlier individual releases. A pool can avoid repeated native calls but add cache misses or synchronization. Compare complete workloads, including cancellation and large requests, rather than timing a repeated allocate-free loop whose working set stays unrealistically small.

The function lab illustrates a specific payload that an arena cannot make disappear. Let positive x be a normalized batch dimension and a the normalized bytes per entry of a dense square table. With a=1, increasing x from one to two raises y=ax² from one to four. Both values are reachable with the actual controls. The lab does not allocate an arena, align objects, or model fragmentation. It shows why grouping allocations by lifetime does not change an algorithm's quadratic payload requirement. After exploring, identify whether changing the representation or shortening retention would reduce that requirement.