Jemalloc 5.4.0
github.com
github.com
Far from the only case. Trillion dollar companies having sudden interest in your open source project is not necessarily a long term benefit.
https://theconsensus.dev/p/2026/04/16/who-even-uses-jemalloc...
> Development of Jemalloc will transition back to the original open source project: https://github.com/jemalloc/jemalloc. Meta’s fork of the Jemalloc project will be fully archived as part of the transition. We look forward to continuing the collaboration with the community to drive jemalloc.
> See blog post for details: https://engineering.fb.com/2026/03/02/data-infrastructure/in...
P.S. I also wondered whether systemd had any cultural reference to Système D aka Système Débrouillard, but Pottering does not seem to engage in word play on other occasions, so probably not.
> Systemd was launched in April 2010; it adopts various ideas from previous init systems and combines them with a uniform configuration and administration interface. Systemd operates as a background service (daemon) and controls important system configuration tasks including hardware initialisation and the starting of server processes. The developers thought that its name is suitably reminiscent of the French term "système D", an expression that relates to "thinking on your feet" and describes high-speed technical problem-solving abilities such as those displayed by TV action hero MacGyver.
https://web.archive.org/web/20121014173559/http://www.h-onli...
Source: https://brand.systemd.io/
The more you know!
> It is disputed whether the name Wi-Fi is short-form for 'Wireless Fidelity',[34] although the Wi-Fi Alliance did use the advertising slogan "The Standard for Wireless Fidelity" for a short time after the brand name was created,[31][35] referenced "the Wi-Fi (Wireless Fidelity) logo" in a white paper[33] and the Wi-Fi Alliance was also called the "Wireless Fidelity Alliance Inc." in some publications.[36] IEEE, a separate but related organization, has stated "WiFi is a short name for Wireless Fidelity" on their website.[37][38] The name Wi-Fi was partly chosen because it sounds similar to Hi-Fi, which consumers take to mean high fidelity or high quality. Interbrand hoped consumers would find the name catchy, and that they would assume this wireless protocol has high fidelity because of its name.[39]
So it’s not really safe to say it’s not meant to mean wireless fidelity, in fact it sounds pretty likely.
There’s a slow memory leak somewhere in my code but with jemalloc it no longer actually matters.
Thanks to jemalloc team for this!
https://www-users.cse.umn.edu/~arnold/disasters/patriot.html
The main issue is thread preemption while you're holding a per-core cache mutex. Some other thread can't do meaningful work using the cache while the holder is sleeping.
If you use a CPU-local data structure, you must handle the case where, mid-way through a call to your allocator, the CPU runs a second thread that makes another call to your allocator (and that, too, can get interrupted by another thread that allocates memory, etc.)
That makes thread-local easier to implement and likely faster (it doesn’t require any memory barriers in the fast path)
Also, good schedulers try to avoid moving threads between CPUs. The better they manage to do that, the lower the cost of having per thread data structures (there likely still is a price, as there most of the time are more threads than CPUs on a system)
i don’t believe rseq based cpu local caches require memory barriers on the fast path.
rseq_cs
The rseq_cs field is a pointer to a struct rseq_cs. Is is NULL when no
rseq assembly block critical section is active for the registered
thread. Setting it to point to a critical section descriptor (struct
rseq_cs) marks the beginning of the critical section.
No explicit memory barrier is required anywhere as the value is only read in supervisor mode and a privilege switch implicitly issues a LS-LS barrier on all major architectures. Even if you did not want to rely on that, you would only need a single S-LS barrier when you store the control structure the very first time.
Aha! So, to take advantage of that, a memory allocator uses the same abort handler for all operations?
If `rseq_cs` is no longer describing a relevant address, that is, the program counter has moved past it, the kernel just ignores it.
The code is executed by a single thread. Everything retires in program order. There is no need for a memory barrier between starting the critical section and its body.
Meanwhile the better the scheduler performs the more competitive the thread local approach becomes.
cost for interruption in an rseq critical section is that the PC gets overwritten to the rseq abort entry point before the task is rescheduled. no management thread necessary.
should be fairly minimal cost, especially assuming interruptions in the critical section are rare.
Giving it some more thought, I expect caches will typically be wiped out by a context switch. So the only place rseq is likely to benefit an allocator is on systems with multiple NUMA nodes where you'd like to make sure any management code isn't paying a penalty by hitting the wrong address range.
IIUC rseq (ie CPU local data) is primarily good for two things. The first being obviating the need for atomics (specifically the resultant cache line ping-pong) but thread local data already accomplishes that. The second being massive oversubscription of physical CPU cores (ie tens of thousands of threads) where TLS becomes utterly wasteful while also thrashing the cache.
maybe i give it too much weight, but:
> massive oversubscription of physical CPU cores (ie tens of thousands of threads) where TLS becomes utterly wasteful while also thrashing the cache
seems worth solving to me
If we do decide to concern ourselves with performance TLS has zero overhead and doesn't suffer from contention while rseq (at minimum) carries a penalty if preempted and involves setting a flag plus exhibits a data dependence for the address offset (the latter since AFAIK compilers don't natively support it as they do TLS). So while I'm certainly open to benchmarks to me it very much looks like a mixed bag that only comes up when you're already in questionable territory to begin with. In the event that we do step outside the norm I'd guess that a handful of threads with contention is a much more common scenario than thousands of threads per physical core exhibiting only minimal preemption.
I also expect something like a web server servicing thousands of requests in parallel to use an event loop instead of spawning an equivalent number of threads. I'm struggling to come up with a scenario where you haven't already fatally shot yourself in the foot and this remains a useful optimization to make. It's certainly relevant if you're using fibers (green threads, whatever you want to call them) but at that point you aren't in c calling malloc and your language runtime will (one hopes) already be taking care of all this for you.
Totally fair, and I agree that you should only have a few threads (or TPC) and shouldn’t be inundating the allocator with requests. But I’m only grinding this axe because I’ve personally had to deal with a system that went against most of that guidance.
We ran far too many threads in a memory-constrained environment. Thread count was many multiples of core count.
I totally agree that this is “questionable territory”, but honestly, any application that’s outgrown the basic glibc malloc has made a few mistakes.
tcmalloc only works on Linux.
Is Meta still using it and developing it? If not who are the driving force behind it now? I just checked there wasn't a release since 2022 and then we have this now. Something changed?
Just wish we have a little bit of context. But it is also great it is continue being maintained. It makes a huge difference for Ruby on Rails Apps.
See the comment of vocx2tx
Why would the scads of people writing JavaScript, Java, python, go, rails, etc need to be aware of jemalloc?
In our Python program, a bit of numpy processing of large pictures led to 100 GB not being returned to the OS by glibc's default allocator and the machine running out of memory shortly after. With jemalloc's reliable memory return settings, those problems disappear.
This is controlled by jemalloc settings `dirty_decay_ms`, `muzzy_decay_ms`, and their interaction with `background_thread`.
`dirty_decay_ms` currently defaults to 10 seconds, so it's not that instant.
That is important e.g. for single-threaded programs that start other programs, such as my Python example: If it starts a subprocess before the 10 seconds elapse after `free()`, Python (and jemalloc) do not run, and get no chance to return memory to the OS.
In such cases, either enable `background_thread`, or set the `_decay_` values to `0` to ensure immediate return to the OS upon `free()`. (This costs some performance.)
The number of programmers who are in positions to care about jemalloc vs other malloc is minuscule
and even then recently it costed (us) quite a few months to blame JVM and later the default glibc memory allocator for running out native (not java heap memory) - had to exclude all possible native libs (zlib, zstd via jna), direct buffers, sockets, thread stacks and so on. Changing the malloc to jemalloc solved the issue, even though initially it was done for its debugging capabilities.
It's just a great memory allocator.
I wish that wasn't the case, but it is.
I work for the runtime team of JPG @ Oracle. We use malloc in Hotspot, quite a lot actually! Providing your JVM with a good malloc can improve the performance of the runtime, both in terms of CPU and memory, by quite a bit.
I don't think you need the details, but it's good to be aware that some mallocs are better than others, and there are multiple of them. Being aware of jemalloc is a good way of being aware of the facts I just mentioned :-).
Writing allocators for domain-specific access patterns is easy. Writing a general-purpose high performing, stable allocator with bounded P99 latency is hard.
Give your friend, Dunning–Kruger, some better pills to keep him from speaking through you.
And that's rather hard, because a general purpose allocator makes all decisions based only on the requested size. This is a very simple interface and such a tool is worth having. But a custom allocator can both bake in a specific scenario and provide more nuanced interaction.
My first thought would be to use per thread pool allocators.
Should one even want a global, general purpose heap allocator for that? Seems like a crazy idea to even consider.
This question was not necessary. You know the answer, because people upvoted this.