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
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.
Replying to
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
Please, let's work together to get the offenders fixed upstream. This affects musl's current and future allocators too and we're not going to penalize reasonable apps with ridiculous memory bloat to facilitate these app bugs.
1
1
Replying to
My approach to this won't increase actual memory usage, but I'd still rather not do it. It doesn't impact small allocations because the size classes are already divided up into 4 per doubling in size for efficiency reasons. That part is explained here: github.com/AndroidHardeni.
1
Show replies