GrapheneOS uses our hardened_malloc allocator (github.com/GrapheneOS/har) with all the optional security features enabled.
The optional slab quarantine features inherently need to use a substantial amount of memory in order to delay reuse of slab allocations as long as possible.
Conversation
We're working on substantially reducing overall system memory usage for the slab quarantine by making mallopt(M_PURGE, 0) aggressively purge memory in it.
Android calls mallopt(M_PURGE, 0) at opportune times when a latency spike is fine such as after an app goes into background.
1
2
The hardened_malloc memory usage without the slab quarantine is already very good and can't really be improved much further. Holding onto as many slab allocations for as long as possible to delay reuse inherently holds onto a lot of memory though, spread across a bunch of slabs.
1
2
The extended size class configuration option expands raises the maximum slab allocation size class from 16k to 128k. These extended size classes are all page aligned and can be purged.
For smaller sizes, slabs with only free and quarantined slots within them can also be purged.
Replying to
It's very difficult to fit this quarantine purging into the regular allocation handling without killing performance. It would be very complex to figure out a reasonable way of doing it fitting in with the rest of the allocator design. If only system calls weren't so slow...
1
2
The baseline allocator already converts empty slabs to free slabs by replacing the memory with fresh pages. It works very well and memory is released back to the system quickly. However the quarantine gets in the way since quarantined allocation slots can't be considered freed.
2