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
It's all fine with server and command-line applications and on Android, but GTK+ and Qt applications often take a ridiculously long time to load because applications feel like reallocating 32 bytes to 32 MiB via realloc loops in increments of 32 bytes. Krita is particularly bad.
2
2
8
Epiphany does a lot of this but it's also packed full of memory corruption so it's hard to test performance... not that anyone should be using such an insecure browser anyway. Even Firefox's lack of meaningful sandboxing and other issues are way less bad than the WebKitGTK mess.
2
4
I find it shocking how poorly desktop Linux applications other than Firefox/Chromium hold up to being run with memory corruption mitigations. It's ridiculous to use C or C++ without any ASan/UBSan testing in 2019. Qt forces lots of undefined behavior in the framework itself...
2
6
13
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
Show replies