Does deleting a large Python list return its memory to the operating system?

### Two different questions hide inside "is the memory freed?" When you write `del records` (or rebind the name, or let a local go out of scope), CPython drops one reference. If that was the last reference, the object is deallocated **immediately** — CPython's reference counting is deterministic, so there is no pause and no waiting for a collector. At that instant the memory the object occupied is free *inside the interpreter*. Whether the **process** gives those bytes back to the kernel is a separate question, and the answer is usually "not yet". That is what people are really asking when `del` on a huge list does not move the resident set size (RSS) they see in a process monitor. ### The layer that decides: pymalloc CPython does not call the C library's `malloc` once per Python object — an object graph of a few million dicts would spend most of its time in the system allocator. Instead, every request of **512 bytes or less** goes to CPython's own small-object allocator, *pymalloc*: * pymalloc requests memory from the OS in **arenas**, 1 MiB each on CPython 3.14 (they were 256 KiB before 3.10). * Each arena is cut into **pools** of 16 KiB. A pool is dedicated to one *size class* — 16, 32, 48 … up to 512 bytes, 32 classes in all, each rounded to a 16-byte boundary. * A pool hands out fixed-size **blocks** from a free list. Allocating a small object is a pointer pop; freeing it is a pointer push back onto that pool's free list. `sys._debugmallocstats()` prints exactly this structure, starting with the line `Small block threshold = 512, in 32 size classes.` Requests **larger than 512 bytes** skip pymalloc entirely and go to the system allocator. A 50 MB `bytes` object, or a list's internal pointer array once it grows past that threshold, is a plain `malloc`/`free` pair. ### Why the memory stays with the process Freeing a small object returns its block to a pool free list — memory the interpreter will reuse for the next object of that size class, but memory the OS still counts as yours. pymalloc releases an arena back to the OS **only when every pool in that arena is completely empty**. One surviving 50-byte object anywhere in a 1 MiB arena pins the entire megabyte. That is why RSS after a spike behaves like a ratchet: it climbs to the high-water mark of your workload and then sits there. It is not a leak — the space is reused. If you run the same batch again, RSS typically does not grow further, and that flatness is the signal that nothing is actually leaking. The system allocator adds its own retention on the >512-byte path. A glibc-style `malloc` satisfies large requests with `mmap` and can `munmap` them on `free` (so a single huge `bytes` object often *does* return promptly), but it keeps smaller chunks on its own free lists and only trims the heap when the top of it is free. ### Measuring it honestly `sys.getallocatedblocks()` reports how many pymalloc blocks are currently allocated. Watching it across a build-and-drop cycle separates the two questions cleanly: the block count returning to its baseline proves the objects really were deallocated, even while RSS stays flat at the peak. ```python import gc, sys base = sys.getallocatedblocks() records = [{"sku": i} for i in range(200_000)] peak = sys.getallocatedblocks() del records gc.collect() print(base, peak, sys.getallocatedblocks()) # e.g. 24236 623615 23504 ``` ### What to do about it If a plateau at the peak is unacceptable, you do not fight the allocator, you change the shape of the work: process the data in smaller chunks so the high-water mark is lower; hold bulk data in one large buffer object (`bytes`, `bytearray`, `array.array`) that bypasses pymalloc and is released in one piece; or run the memory-hungry phase in a short-lived child process so the whole address space goes away when it exits. Calling `gc.collect()` does not shrink the process — it only breaks reference cycles so the objects in them can be deallocated in the first place.