Conversation

Replying to
github.com/GrapheneOS/har is certainly balancing performance, memory usage and security too. It takes a much different approach inherited from allocators like OpenBSD malloc rather than allocators like dlmalloc and is specifically designed around the large address space on 64-bit.
1
Replying to and
There's some documentation on the approach in the README. It was written to be a replacement for the previous port of OpenBSD malloc and shares a lot of the basic design concepts with it. It does lean more towards security than performance and cares a lot about low fragmentation.
1
Replying to and
I would be using a slab allocator approach with out-of-line slab metadata even for a fully performance oriented allocator, like the Linux kernel. Bitmaps instead of free lists is the main difference from a pure performance-oriented approach but jemalloc uses bitmaps to pack data.
1
Replying to and
That could still be a perfectly suitable approach in a purely performance-oriented allocator. I'd just throw away all the security features layered on top, replace bitmaps with free lists and add small array-based thread caches like jemalloc to amortize the cost of locking.
1
Replying to and
Scalability primarily comes from having locking divided up per-arena and per-size-class within the arenas, so with 4 arenas, there are 4 separate sets of size class regions, each with their own entirely independent locking (there is no global or arena-level locking for slabs).
1
Show replies