> but it suggests strongly that the heuristics in malloc either have a bug, or the parameters aren't set aggressively enough I think the author might be being

> but it suggests strongly that the heuristics in malloc either have a bug, or the parameters aren't set aggressively enough I think the author might be being a bit naive about the role of the allocator. Sure, it could aggressively madvise()/munmap() unused pages to return them to the kernel but as soon as memory is needed again there's a significant overhead to bring it back again. For desktop apps it might be fine to run with few spare pages (and save the RAM) but doing so on a busy server would likely result in different inefficiencies. jemalloc used to have an option (opt.lg_dirty_mult: https://linux.die.net/man/3/jemalloc https://linux.die.net/man/3/jemalloc) to control how many dirty pages it'd allow to build up before calling madvise(.., MADV_FREE) to give them back to the OS. This allowed one to choose between saving CPU by maintaining free pages or saving RAM by giving them back. Later jemallocs switched to decay-based purging of dirty pages (via a dedicated thread) to get the best of both worlds.