Three prevailing themes in the discussion
| Theme | Key points | Representative quotes |
|---|---|---|
| 1. Performance & benchmarking of allocators | Users compare jemalloc, mimalloc, tcmalloc, and glibc, stressing that benchmarks can be misleading if not tied to real workloads. | “I’ve been using jemalloc for over 10 years and don’t really see a need for it to be updated. It always holds up in benchmarks against any new flavor of the month malloc that comes out.” – codexon “Benchmarks age fast. Treating a ten‑year‑old allocator as done just because it still wins old tests is tempting fate…” – hrmtst93837 “You really need to benchmark your workloads, ideally with the ‘big 3’ (jemalloc, tcmalloc, mimalloc). They all have their strengths and weaknesses.” – imp0cat |
| 2. Need for specialized / expressive allocation interfaces | The community argues that generic malloc/realloc is insufficient; specialized allocators or richer APIs can yield better performance and memory usage. |
“If there is so much performance difference among generic allocators, it means you need semantic optimized allocators.” – sylware “I feel like the real thing that needs to change is we need a more expressive allocation interface than just malloc/realloc.” – IshKebab “The one size fits all was never a solution.” – pjmlp |
| 3. Corporate stewardship of jemalloc | Meta’s takeover and continued maintenance of jemalloc, the archiving of the original repo, and the implications for the open‑source community are debated. | “Meta never abandoned jemalloc. Meta still maintained it and actively pushed commits to it fixing bugs and adding improvements.” – charcircuit “The repo’s availability isn’t related to whether it’s still maintained.” – kstrauser “Jason Evans (the creator of jemalloc) recounted the entire thing last year…” – masklinn |