How does CPython's pymalloc allocator handle small objects differently from malloc?

### The problem pymalloc solves Almost every Python value is a heap object with a header, and typical objects are tiny: a small `tuple`, a `float`, a dict entry table, an `int`. A program that builds a million of them would make a million `malloc` calls and a million `free` calls. General-purpose system allocators are built for a mix of sizes and for arbitrary threads; paying their bookkeeping for a 32-byte object dominates the cost of creating it. CPython therefore puts its own **small-object allocator**, pymalloc, in front of the system allocator. On CPython 3.14's standard build it handles every request of **512 bytes or less**; anything larger falls straight through to `malloc`. ### The three-level layout: arena, pool, block * **Arena** — the unit pymalloc buys from the OS, 1 MiB on 3.14 (raised from 256 KiB in 3.10), obtained with `mmap` where available. * **Pool** — a 16 KiB slice of an arena (4 KiB before 3.10). A pool is assigned to exactly one *size class* while it holds anything. * **Block** — a fixed-size slot inside a pool. Sizes are multiples of 16 bytes: 16, 32, 48 … 512, giving 32 size classes. A 40-byte request is rounded up to the 48-byte class, and the difference is what `sys._debugmallocstats()` calls "bytes lost to quantization". Allocation is a free-list pop from the pool that currently serves that size class; deallocation is a push back onto it. Both are a handful of instructions with no system call, which is the entire point. Empty pools return to their arena's pool pool, and a fully empty arena is handed back to the OS. ### What it means in practice **Fragmentation is arena-shaped.** Because an arena is released only when it is entirely empty, a few long-lived small objects scattered across many arenas can keep megabytes resident long after the bulk of the data is gone. This is the mechanism behind "my RSS never comes back down". **The 512-byte line changes behaviour.** Bulk data held in one large object — a `bytes`, a `bytearray`, an `array.array`, a big buffer viewed through a `memoryview` — never touches pymalloc, so its memory is returned on the system allocator's terms rather than pinned by arena occupancy. Holding the same bytes as a million small objects is the opposite case. **pymalloc is not general-purpose thread-safe.** In the standard build it relies on the GIL for mutual exclusion, which is why the free-threaded build (experimental in 3.13, officially supported in 3.14 by PEP 779) uses **mimalloc** as its object allocator instead: mimalloc is thread-safe by design with per-thread heaps. ### Inspecting it Two stdlib entry points expose the allocator directly: ```python import sys print(sys.getallocatedblocks()) # live pymalloc blocks sys._debugmallocstats() # size-class table, pool and arena counts, to stderr ``` `sys._debugmallocstats()` prints the per-size-class table (pools in use, blocks in use, available blocks), then the arena summary: arenas allocated, bytes in allocated blocks, bytes in available blocks, unused pools, and bytes lost to pool headers, quantization and alignment. Comparing *bytes in allocated blocks* against *arenas × 1 MiB* is a direct read on how fragmented the heap is. `sys.getallocatedblocks()` counts pymalloc blocks specifically — under `PYTHONMALLOC=malloc` it reports 0, because pymalloc is not the one doing the allocating. ### The boundaries worth stating in an interview pymalloc sits between Python objects and the C library, not between your program and virtual memory: it does not do compaction, it never moves an object (C extensions hold raw pointers into these blocks, so addresses must be stable), and it has nothing to do with reclaiming *garbage* — deciding that an object is dead is reference counting's job, and breaking cycles is the collector's. pymalloc only answers "where do the bytes come from, and where do they go back to".