What is malloc doing, anyway?

The piece explains how malloc turns small allocation requests into usable memory without asking the kernel for every block. A process has a virtual address space containing code, data, heap, libraries, and stack; most of the vast gaps between these regions are unmapped and use no physical RAM. A simple allocator that calls sbrk for each request is costly: the measured syscall takes about 575 ns, sbrk about 610 ns, and malloc(16) only 26.9 ns. The explanation builds a toy allocator that requests heap space in 64 KiB batches, adds headers to record chunk sizes, and tracks freed chunks in a list. It splits large free chunks to satisfy requests and merges adjacent chunks when memory is freed, allowing reuse rather than endlessly growing the heap.

The discussion then distinguishes virtual memory from resident memory. Newly extended heap space costs little RAM until pages are written; writing to a 1 GiB region produces roughly 262,000 page faults and raises resident memory to about 1 GiB. Freed heap memory can be returned by lowering the program break only when a free chunk reaches the heap’s top, so gaps trapped beneath live allocations remain resident and contribute to fragmentation. For large allocations, the allocator can instead use anonymous mmap, which creates a separate mapping that can be returned with munmap when freed, regardless of neighboring allocations. Together, these mechanisms explain why malloc’s simple interface hides bookkeeping, batching, reuse, and different strategies for small and large blocks.