Allocators can be optimized for different things. Minimum metadata usage, fast small allocations, fast free, fast larger allocations, etc. So you can get some decent wins by customizing your allocator for your specific workload even if the interface stays the same.
So much so that it can’t be configurable? I can imagine Firefox’s customizations would be useful to other people. It seems driven by the C/C++ situation where sharing common modules is so difficult that “copy & customize” seems easier.
Allocation is a fairly complex task - you have to give out memory while avoiding fragmentation, obviously, but also track a bunch of metadata and support all of this concurrently, and CPU and memory overhead from all this needs to be kept to an absolute minimum. So there’s a fair amount of complex algorithms, trade-offs, etc, all of which can be tweaked. I suspect it’s a combination of tweaking to work better in Firefox’s specific case (maybe Firefox makes allocations more frequently, or has shorter-lived allocations, I have no idea - the point is the trade-offs aren’t necessarily generic), and just general improvements they haven’t gotten around to upstreaming.
I, too, spin in user-space and never sleep.
On the off chance that anyone might know: is there a formal process for moving things like this from undocumented to documented & supported status?
Why would one customize an allocator? I always assumed allocation is fairly generic
Allocators can be optimized for different things. Minimum metadata usage, fast small allocations, fast free, fast larger allocations, etc. So you can get some decent wins by customizing your allocator for your specific workload even if the interface stays the same.
This post illustrates why: they’ve modified the locking in stock jemalloc to perform better on loaded systems.
So much so that it can’t be configurable? I can imagine Firefox’s customizations would be useful to other people. It seems driven by the C/C++ situation where sharing common modules is so difficult that “copy & customize” seems easier.
Allocation is a fairly complex task - you have to give out memory while avoiding fragmentation, obviously, but also track a bunch of metadata and support all of this concurrently, and CPU and memory overhead from all this needs to be kept to an absolute minimum. So there’s a fair amount of complex algorithms, trade-offs, etc, all of which can be tweaked. I suspect it’s a combination of tweaking to work better in Firefox’s specific case (maybe Firefox makes allocations more frequently, or has shorter-lived allocations, I have no idea - the point is the trade-offs aren’t necessarily generic), and just general improvements they haven’t gotten around to upstreaming.