Changing the default userspace memory allocator for a distribution is less a technical choice than you think: lists.fedoraproject.org/archives/list/
Conversation
Replying to
I always found the goal of the default allocator be better on the secure side and for short running tools.
There is no point in using the glibc allocator when switching to tcmalloc (for MySQL) frees up multiple whole CPU cores...
1
1
You're not really giving up security using a modern allocator. glibc malloc has all the allocations mixed together with inline metadata and address space reused, etc. It has a few sanity checks for their linked list management. Modern allocators don't have that inline metadata.
1
1
Modern allocators have out-of-line region and slab metadata for memory usage and performance reasons. It's incredibly wasteful to have a 16 byte header on every 16 byte allocation, and you just don't need to do that with the much lower fragmentation slab allocation approaches.
1
1
A performance-oriented allocator will likely use free lists for within slabs inside the freed allocations. A security-oriented allocator will use bitmaps. Either way, there's only going to be around 32 to 128 bytes of metadata overhead per slab which will be at least 4096 bytes.
As an example, jemalloc has out-of-line region metadata including the run (slab) metadata. It uses array-based thread caching with thread cache GC. It's more cache friendly than free lists. They do use free lists for arena caching, but underneath that cache they use bitmaps.
1
1
Why do they use bitmaps? It helps them pack memory by filling the free slots within a run (slab) in order instead of an arbitrary order based on when they were freed as you get with a free list. Wins massively on perf and memory use vs. glibc malloc for long running processes.
1
1
Show replies