I was a bit reluctant to do it, but I ended up extending the size class scheme to large allocations like jemalloc:
github.com/GrapheneOS/har
It speeds up launching applications like Krita by 2-3x. It will make less difference when slab size classes cover more than 16k by default.
Conversation
The size class calculation implemented for this is neat:
github.com/GrapheneOS/har
It has the potential to replace the small size class table used to calculate those, but they'd also need to calculate the class index used to find metadata with size_class_metadata[arena][class].
1
1
1
I can't justify not having it enabled by default when there's pervasive pathological incremental realloc in GTK/Qt applications. Small size classes already do this for a different reason (balancing internal vs. external waste) and for large it's only virtual memory.
1
It's also worth noting that the initial large allocations sizes already followed this scheme because 4k is the initial spacing class, since 2k is the final slab spacing class right now: 4 KiB [20 KiB, 24 KiB, 28 KiB, 32 KiB]. Extended slab allocator classes will match these too.
Replying to
An alternative proposed by is tracking small reallocs with a counter (would be here github.com/GrapheneOS/har) as a heuristic to start rounding. It's a 64-bit only allocator and it's virtual memory, so it might be better to save an initial few realloc calls though.
1