github.com/GrapheneOS/har
Not my area but maybe this could be useful to look at?
This Tweet was deleted by the Tweet author. Learn more
Conversation
hardened_malloc uses per-arena-per-size-class locking. If you set the number of arenas to a decent amount (jemalloc uses 4x the number of cores) and turn off the optional security features, it has better performance / scaling than glibc and jemalloc for mid-sized allocations.
1
It can't compete for small allocations due to the lack of thread caching. Thread caching heavily conflicts with hardening as explained in github.com/GrapheneOS/har. The baseline fully out-of-line metadata design has little performance cost though. The performance cost comes from...
1
... lack of thread caching and optional features like zero-on-free, checking for zero on allocation, random + FIFO quarantines, slot rand, canaries, etc. which add up to substantial overhead when it's all enabled. The core design is fast. Out-of-line metadata isn't expensive.
1
In fact, the baseline design would be a great fit for a low-fragmentation performance-oriented allocator. Rip out all the sanity checks and optional security features and add array-based thread-caches (still out-of-line metadata). Out-of-line metadata is good for performance.
1
Quote Tweet
A non-obvious thing about malloc that even very perf-y people often don't note right away: since you write to it before reading from it, cache locality of the result is less important than that of malloc metadata. Once callers have the address, they can work in the store buffer.
Show this thread