3 ms·

… the allocator can only do so much. If there's a small allocation after a large one, and the large on is freed and the small one held forever, you may never be

• flohofwoe 4y ago
  The OS just gives you new chunks of memory, but it's the job of the application to manage the memory it has been given by the OS. Modern general purpose allocators are a bit more clever then just grabbing the next available address from a single free-list, usually they group allocations by size into buckets. Then there's specialized allocators (e.g. arena, bump, stack ...) which not only prevent fragmentation but also increase memory management performance. In general, memory fragmentation in a limited address space is only a problem for programs that don't have a proper memory management strategy.
  • deathanatos 4y ago
    I'm aware of all of the things that you mention, and you can assume that the allocator I am discussing here is reasonably intelligent and does all of those things. Even with everything you mentioned, the point is that the allocator (doing all those things) cannot return free memory to the OS, because the APIs simply don't exist for it: that's what mmap() provides over sbrk(). In the worst case, even for an allocator doing all those things, this can result in an allocator being unable to return any memory: if exactly the last allocation remains alive, sbrk() cannot be called (as you'd free a still-live allocation); but in the case of mmap(), we can free most, or in the best case, all of the memory not in actual use.