Why free() Keeps Memory in Your Process Instead of Returning It to the OS

When a C program frees allocated memory, the memory is not immediately returned to the operating system but is instead held by the allocator — an intermediate layer that manages memory pools to reduce costly kernel syscalls. The glibc allocator (ptmalloc2) uses two mechanisms to obtain memory from the kernel: brk/sbrk for small allocations and mmap for large ones above a 128 KB threshold. Freed memory is placed into bins organized by size, allowing future allocations to reuse blocks without involving the kernel, which explains why a process's resident memory (RSS) remains high even after freeing all data. Each allocated block carries a hidden metadata header storing size and flag information, and freed chunks reuse the same memory space to store free-list pointers — a design that also underlies certain memory corruption exploits. For workloads where glibc's default behavior causes fragmentation or memory retention issues, alternative allocators such as jemalloc or tcmalloc may offer better performance and memory return characteristics.