Allocator efficiency was the primary concern in the past (both speed and packing), which is why there are several things in malloc which is obviously bad for al

Allocator efficiency was the primary concern in the past (both speed and packing), which is why there are several things in malloc which is obviously bad for allocation safety. The allocators in the past have tried to use the space it is not currently using for user code for its own book-keeping, which is very efficient when it comes to usage of space. So the free-lists are interleaved with the actual allocations to be as cheap as they can be (not in a different page). Oddly enough, packing all the metadata in a single area might actually be faster though at lower scales might be worse for the data itself. I've used talloc[1] in the past, which traded some of the efficiencies for safety (I have my own sins trying to copy, but simplify pool based allocators for PHP apc with some tricks[3] borrowed from xcache). If the author is reading, the missing magic I've always missed with jemalloc are the .gdb macros for walking the allocator and do things like print the allocations by size/content [2]. You can write them in python now and that can let you print them out neatly in a graphviz dot structure with linkages, which is the sort of project which you hand out to an intern who just joined. [1] - https://talloc.samba.org/talloc/doc/html/libtalloc__dts.html https://talloc.samba.org/talloc/doc/html/libtalloc__dts.html [2] - https://research.nccgroup.com/2015/08/11/libtalloc-a-gdb-plugin-for-analysing-the-talloc-heap/ https://research.nccgroup.com/2015/08/11/libtalloc-a-gdb-plu... [3] - http://notmysock.org/blog/2009/Jan/08/ http://notmysock.org/blog/2009/Jan/08/