Jemalloc Postmortem

End of upstream jemalloc & Meta’s role

• Original upstream is effectively finished; Meta maintains an internal fork focused on its own workloads.
• Commenters note this leaves no steward with a “general utility” perspective, though Meta may still drive improvements that incidentally help others.
• Some regret that external consumers lost an upstream that was responsive to their needs and bug reports.

Impact on users and dependent projects

• Widely used in Redis/Valkey, Firefox, Rails deployments, image‑processing stacks (libvips, Go image servers), RocksDB users, and various game engines.
• Many report dramatic, “flip a switch” wins: reduced fragmentation, fewer OOMs, and big CPU savings.
• Projects now face choices: keep a frozen jemalloc (accepting open bugs), fork and maintain, migrate to another allocator, or hope a new maintainer emerges.

Is a memory allocator ever “done”?

• One camp: allocators are maintenance treadmills due to new CPU features, kernel behaviors (THP, rseq), changing page sizes, language/runtime changes, and evolving allocation patterns. Without ongoing tuning, performance and behavior degrade.
• Opposing camp: mature software can be “done”; aside from bugs/security, it doesn’t rot unless its environment breaks it. They see continual churn as unnecessary.

Alternatives: mimalloc, tcmalloc, others

• mimalloc is frequently recommended; said to match or beat jemalloc in some workloads (CPython switched to it), though profiling tools are weaker and macOS interposition support is less proven.
• tcmalloc is praised technically but seen as hard to use outside Google: Bazel‑centric, sensitive to specific Linux configs, and historically poor at releasing memory (newer work improves this).
• snmalloc also mentioned; Apple uses its own libmalloc.

Why jemalloc isn’t the default everywhere

• On FreeBSD it is; on glibc systems, reasons cited include licensing/copyright‑policy friction, politics, startup overhead for short‑lived tools, and conservatism around letting a third‑party/megacorp effectively become glibc’s allocator.

Fragmentation and returning memory

• glibc’s allocator is criticized for severe fragmentation and reluctance/quirks in returning memory to the OS, leading to surprising OOMs despite frees.
• jemalloc and others are seen as better at fragmentation and tunable release behavior, though containerized environments shift the cost/benefit of returning memory.

Usability, build systems, and governance

• A recurring theme is that great allocators are hindered by hard‑to‑integrate build systems (especially Bazel); “usability” includes build/link ergonomics.
• Some draw a lesson about relying too heavily on a single megacorp; others argue the decade of funded development was a worthwhile trade, and the code remains available to fork.