snmalloc
jemallocator
| snmalloc | jemallocator | |
|---|---|---|
| 8 | 2 | |
| 1,491 | 310 | |
| 1.3% | 4.5% | |
| 6.3 | 5.4 | |
| about 1 month ago | 9 days ago | |
| C++ | Rust | |
| MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
snmalloc
-
Snmalloc: A Message Passing Allocator
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.
-
Is the JVM a upside or downside to Scala?
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.
- Snmalloc 0.6 released, major redesign with security hardening
- Snmalloc: High-performance message passing based allocator
-
Maintenance status (jemallocator)
Did you ever benchmark against https://github.com/microsoft/snmalloc ?
jemallocator
-
Bizarre memory leak caused by tokio runtime
I was able to replicate the issue with the sample code, but not when using a different allocator (https://github.com/tikv/jemallocator). I understand the default allocator on Linux is malloc (https://doc.rust-lang.org/std/alloc/struct.System.html), and while looking up the differences between the two, it seems like jemalloc handles memory fragmentation much better (https://engineering.linkedin.com/blog/2021/taming-memory-fragmentation-in-venice-with-jemalloc). Maybe that's what's going on?
-
Maintenance status (jemallocator)
There's an actively-maintained "simplified" fork at https://github.com/tikv/jemallocator.
What are some alternatives?
mimalloc - mimalloc is a compact general purpose allocator with excellent performance.
Mesh - A memory allocator that automatically reduces the memory footprint of C/C++ applications.
jemallocator - Rust allocator using jemalloc as a backend
mimalloc_rust - A Rust wrapper over Microsoft's MiMalloc memory allocator
rust - Empowering everyone to build reliable and efficient software.
rpmalloc - Public domain cross platform lock free thread caching 16-byte aligned memory allocator implemented in C
rkyv - Zero-copy deserialization framework for Rust
o1heap - Constant-complexity deterministic memory allocator (heap) for hard real-time high-integrity embedded systems. There is very little activity because the project is finished and does not require further changes.
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...