Understand CPython's Memory Allocator: obmalloc

CPython's obmalloc

Most \`malloc\` calls in CPython do not hit the system allocator directly. \`obmalloc\` in \`Objects/obmalloc.c\` layers pools, arenas, and size classes tuned for small, short-lived objects.

Pool Architecture

Allocation tiers:

• Pools: 4 KiB blocks carved into blocks of one size class
• Arenas: large chunks (256 KiB) holding many pools
• Raw allocator: falls through to \`malloc\` for oversized requests

Small object requests (typical \`PyObject\` headers plus payload) are served from a free list inside a pool, avoiding syscall overhead and reducing fragmentation.

For example, allocating thousands of identical small tuples reuses slots from the same pool rather than calling \`malloc\` each time.

Stats to watch: pool utilization, arena count, and fallback rate to the system allocator under memory pressure.

Design Notes

Falling through to system `malloc` for large allocations is intentional. Pool exhaustion under fragmentation is a sign workloads allocate many different sizes; watch arena growth in long-running servers.

For This Exercise

This exercise asks you to document obmalloc's pool and arena design. You will explain why Python allocates small objects differently than a generic \`malloc\` and how that shapes interpreter performance.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.