Due to the way pools allocate and free memory from the allocator, the blocks that are allocated last (and therefore have the highest addresses) tend to be freed first. However, if max_free_index is set, the allocator will keep the blocks that have been freed first in the free list and return the blocks that have been freed last to libc with free(). This means that the memory blocks with the highest addresses tend to stick in the free list. Therefore libc malloc() implementations that use brk/sbrk can never return much memory to the OS, because there are always blocks at the top of the address space still in use.

An additional problem is that once a larger block has been put into the free list, it can be kept there basically forever if this block size is not used anymore. (The overwhelming majority of used blocks is 8k.) Therefore if such a block has a relatively high address, it will prevent libc's malloc from returning memory to the OS.


I haven't had a good idea yet how to solve this. One could use double linked lists for the free lists and always free() blocks from the back end of the list. But this would enlarge the overhead even in the case where max_free is set to unlimited.