I'm going to need rounding for large allocation sizes like jemalloc to work around poorly written applications and libraries with element-by-element realloc growth loops. GTK+ / Qt ecosystems are full of memory corruption & inefficient patterns like this.
github.com/AndroidHardeni
Conversation
Replying to
I'm working on making this functionality less costly in jemalloc, by keeping a "small-increase counter" in the metadata for realloc'd extents, and only doing a larger-than-asked-for increase if it looks like the user is doing the quadratic growth algorithm.
1
Replying to
Since it's only wasted virtual memory for large allocations, it's already relatively cheap at least on 64-bit. This allocator is inherently 64-bit-only and already adds random guard regions around large allocations that are at least 1 page and up to 50% of the allocation size.
1
1
Part of why it's a huge issue is that I've taken a minimalist approach to the initial size classes by switching to the large allocation scheme once the spacing between sizes reaches 4k (i.e. beyond 16k allocations). I haven't decided how much further it should go by default yet.