Why this matters: an arena is a point on a spectrum, and interviewers probe whether you know the neighborhood — what small extensions preserve the contract, which patterns the arena exists to serve, and how you debug memory that keeps no records. Rehearsing this space is how you answer follow-ups from understanding instead of memory.

Checkpoints: reset, but scoped

reset() rewinds the whole arena, which fits phase-shaped lifetimes. Some workloads have nested phases — a parser that speculatively parses an alternative and wants to abandon just that attempt. The arena's structure supports this almost for free: a checkpoint is a saved position, and rewinding to it un-allocates everything after it.

Checkpoint = (block pointer, saved cursor)

save:    record current block + its cursor
rewind:  restore cursor on that block;
         reset every block chained after it;
         current = the checkpointed block

The contract stays intact — nothing is freed individually; a suffix of the timeline is abandoned wholesale. That's the honest way to describe it, and it shows the interviewer you extend contracts by finding operations they already permit, not by bolting on exceptions.

Growth policy: fixed versus geometric blocks

Our design chains fixed 64 KiB slabs. The alternative is geometric growth — each new block larger than the last — and the trade is worth stating precisely. Fixed blocks keep waste predictable (tail slack is bounded by one slab) and behave well under reset() reuse, since every phase sees the same shape. Geometric growth reduces the number of system allocations for workloads that occasionally balloon, at the price of a bigger worst-case tail and warm blocks whose sizes reflect one unusual phase forever after.

For a request/frame arena that resets constantly, fixed is usually right; for a build-once-then-destroy arena (a compiler pass), geometric saves chain-walking. Tie the policy to the reuse pattern and you've answered the follow-up before it's asked.

Large alignments

The bump handles any power-of-two alignment, but the cost model changes as alignment grows: rounding waste is bounded by align − 1, so a 4096-byte alignment can burn nearly a page per allocation in the worst case. Two honest mitigations exist inside the contract: serve large-alignment requests from their own dedicated blocks (whose bases the system allocator already aligns generously), or group same-alignment allocations together so the padding is paid once per run rather than per allocation. Either way, say the cost out loud — "alignment waste scales with the alignment" — because pretending the bump makes it free is exactly the imprecision systems interviewers press on.

The patterns that justify arenas

Where the arena is the right tool is part of the problem statement, so have the catalog ready:

• Arena per request — a server handler allocates freely, the response is sent, reset(). Allocation cost near zero, no leak possible mid-request, warm blocks amortize across requests.
• Arena per frame — game and UI loops: everything transient in frame N dies at frame N+1's reset. The alternative — individually freeing hundreds of tiny objects per frame — is both slower and easier to get wrong.
• Arena per compilation unit / AST — build the whole tree, use it, destroy it. Node-by-node teardown of a large graph is O(nodes) of pure waste when the lifetime is collective anyway.
• One arena per thread — the sharing answer from our requirements: don't lock an arena, give each worker its own. Isolation by ownership instead of synchronization.

The common thread — collective lifetime — is the test for "is an arena right here?" And the inverse gives the honest "wrong tool" answer: objects with independent, unpredictable lifetimes belong in a general-purpose allocator, which is why the two designs coexist in real systems.

Debugging memory with no records

The arena's no-bookkeeping design cuts both ways: nothing tracks what's live, so use-after-reset bugs are silent by default — the memory is still mapped, still warm, still holding plausible bytes. The standard aids:

• Poisoning — on reset()/rewind, fill reclaimed regions with a recognizable pattern (0xDD…). Dangling readers now see garbage that looks like garbage, and crashes move close to the bug instead of miles downstream.
• Checkpoint discipline in debug builds — assert that rewinds happen in LIFO order of saves, catching mismatched save/rewind pairs early.
• High-water marks — track the deepest cursor per block in debug mode; it costs one comparison and tells you what block size the workload actually wants.