snmalloc

Bad link, this was better, https://github.com/microsoft/snmalloc/blob/main/docs/securit...

https://github.com/microsoft/snmalloc#snmalloc mentions two biggest motivations as: > Allocations on one thread are freed by a different thread I can imagine one use-case for this: a task that is scheduled from and executed by a work-stealing thread-pool can allocate memory in one thread but by design there's no guarantee that the memory will be necessarily freed from that exact thread. Would that be a good use-case for snmalloc? > Deallocations occur in large batches This sounds much like a bump allocator use-case but which can do this exact thing by calling a single munmap(addr, len) and unmap multiple allocations all at once.

While reviewing that doc, I also came across this. Seems very interesting -- I did not know this was possible: > Some architectures, such as CHERI (including Arm's Morello), explicitly consider pointer provenance and bounds in addition to their target addresses. Adding these considerations to the architecture enables software to constrain uses of particular pointers in ways that are not available with traditional protection mechanisms. For example, while code may have a pointer that spans its entire C stack, it may construct a pointer that authorizes access only to a particular stack allocation (e.g., a buffer) and use this latter pointer while copying data. Even if an attacker is able to control the length of the copy, the bounds imposed upon pointers involved can ensure that an overflow is impossible. (On the other hand, if the attacker

I hoped to see benchmark comparisons with newer allocators like mimalloc https://github.com/Microsoft/mimalloc and snmalloc https://github.com/Microsoft/snmalloc as well as the older workhorses like jemalloc, hoard, tcmalloc...

I wonder how realistic/fair the code of some benchmarks is. I just took some small peak at atix (because I happen to know it) and while first all looked fine it wasn't quite that realistic. Mainly: - It uses a fork of tokio-postgres specific for the test (which differs in that Client is no longer send and it has a Unsafely soundness hole by wrongly using Unsafe Cell, and no Issue tracking enabled on, through replacing that cell with RefCell probably yield very similar performance) - Instead of using the default web::Json responder it uses simd-json (EDIT: explicitly encoding the data into a buffer instead of returning it wrapped in web::Json) - Uses snmalloc instead of the default allocator (https://github.com/microsoft/snmalloc) Just to be clear besides the first point all of this is not unrealistic for a context where you want to highly

description at https://github.com/microsoft/snmalloc/blob/master/snmalloc.p...

From the github README: snmalloc is a research allocator. Its key design features are: - Memory that is freed by the same thread that allocated it does not require any synchronising operations. - Freeing memory in a different thread to initially allocated it, does not take any locks and instead uses a novel message passing scheme to return the memory to the original allocator, where it is recycled. - The allocator uses large ranges of pages to reduce the amount of meta-data required. Details about snmalloc's design can be found in the accompanying paper[OP]. Differences between the paper and the current implementation are described here[0]. [0] https://github.com/microsoft/snmalloc/blob/master/difference...