snmalloc VS mimalloc_rust

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.

Yes, it's very efficient and that's not where the main problem lies. However, small allocations with modern C heap allocators like mimalloc or snmalloc has gotten extremely efficient as well. Would be interesting to see a benchmark comparison with Java's G1 and ZGC.

Did you ever benchmark against https://github.com/microsoft/snmalloc ?

> I wish Rust would switch to mimalloc or the latest tcmalloc (not the one in gperftools).

That's nonsensical. Rust uses the system allocators for compatibility, not because they're good (they were not when Rust switched away from jemalloc, and they aren't now).

If you want to use mimalloc in your rust programs, you can just set it as global allocator, that takes all of three lines: https://github.com/purpleprotocol/mimalloc_rust#usage

Context: When using mimalloc as global allocator, linking with crt-static fails with the following error:

Use an optimized memory allocator, my choice is mimalloc. It wins every time I compare it, even against jemalloc (not to mention it supports arena hardening which is good for security).

Version 0.1.19 of the Rust wrapper for the mimalloc memory allocator has just been released!

I'll mention that mimalloc (+ Rust wrapper) is great alternative to jemalloc.