I'm not sure why I didn't make this change sooner:
github.com/GrapheneOS/har
There's not much downside to only having 1 slot per slab once slab allocations are 4096 byte aligned, which is what we refer to as extended size classes. This goes nicely with the guard slab feature.
Conversation
By default, there's an unused guard slab between every possible usable slab that's left as unused PROT_NONE memory.
If the slabs have 1 slot, the allocations have guaranteed guard pages without paying the cost of actually making system calls to set them up during regular usage.
1
1
Having slabs with 1 slot originally wasn't supported but github.com/GrapheneOS/har added support for it.
This does need a tiny little bit of unnecessary work but avoids other work (bitmaps). It's insignificant for allocations this large, especially with zero-on-free, etc. enabled.
1
The normal non-extended size classes are too small to be all be aligned to 4096. There are 4 size classes per doubling in size to have ~20% maximum waste from rounding, like jemalloc. Extended size classes are optional since hardened_malloc can happily use mappings instead.
Replying to
It would also be nice to go through the smaller size classes to see if it makes sense to reduce the number of slots in some cases to further reduce memory usage. It's not really that much of a problem by itself but it will help make the slab allocation quarantine use less memory.
1
Further work will be figuring out how to efficiently purge slabs entirely consisting of quarantined allocations without adding too much overhead. It could start out being done only as part of malloc_trim which Android calls regularly via M_PURGE for background apps, etc.