Development was never stopped for jemalloc. This is a common misconception. There just were not releases being tagged and packaged against the ongoing development.
Why? Writing a memory allocator is quite simple, and I'd argue that _everyone_ should write one from scratch for any kind of high performance application. It's also trivial to outperform general purpose allocators that have to satisfy countless constraints. I've written numerous special purpose mallocs that are a) both provably (formally) safer than the standard armada and b) significantly faster (>10x throughput).
In the Before Times, the vast majority of software was written in garbage collected language where a working knowledge of the relative merits of C memory allocators is not useful or particularly relevant.
Why would the scads of people writing JavaScript, Java, python, go, rails, etc need to be aware of jemalloc?
TL;DR: Because the runtime of most GC:d languages uses malloc for its internal data structures.
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 :-).
The vast majority of professional developers are not in a position where they can just swap out allocators willy-nilly. They take what they get, and write the code they're assigned to write on the platform the CTO or their product lead or whoever has decided upon.
>...the vast majority of software was written in garbage collected language
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 (java heap memory) - had to exclude all possible native libs, 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.
I'm never sure if I should be upset or happy when I've been debugging a problem for long enough that I finally decide to switch something out in order to improve visibility and that immediately solves the problem for entirely unexpected reasons. Particularly all the times when I couldn't readily discern why.
We changed to jemalloc first on a jvm service which we could never get to run in its kube memory limit. with jemalloc its been dead stable for years, and we made it the default for all jvm services
Memory allocation behaviour has visible impact also for users of managed languages, and the behaviour of software for end users.
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.
I'm in the same boat, I just switched to using it for Kavita, which only does some basic open Image -> Thumbnail to smaller size -> write to disk when importing new comics/books and on linux, memory could swell to 10GB and never get released. Switched to jemalloc and instantly memory stayed well below 1GB.
Generally yes, but the wording of "instantly" begs for the following pedantic remark:
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.)
Because unfortunately, the runtimes belonging to all or at least most of those languages perform a lot better with jemalloc than with the system default.
You are not alone - my first thought was 'oh, HN is trying to bring back the disappointed hackers'. All this AI hype over every little model update fart is so exhausting and boring …
> I don’t want to dwell on drama, but it is perhaps worth mentioning that we reached a sad end for jemalloc in the hands of Facebook/Meta even though most of the people involved were acting in good faith.
Far from the only case. Trillion dollar companies having sudden interest in your open source project is not necessarily a long term benefit.
> 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.
Rather a tradition to call a malloc by the initials of the implementer: Jason Evans malloc (jemalloc), Poul-Henning Kamp malloc (phkmalloc), Doug Lea (dlmalloc).
(I also wondered whether systemd had any cultural reference to Système D aka Système Débrouillard), but Pottering does not seem to have a particular taste for jokes ;-)
"Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d."
> 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.
Fun grammatical fact that I only learned after years of speaking French: when borrowing words from other languages, you usually (not always) take the gender of the equivalent word in French, so technically it would be “de la memory” :)
An interesting case is "WiFi", short for "wireless fidelity". "Fidélité sans fil" in French should be feminine, but every technical person says "le WiFi" (masculine) while many (most?) non-technical people intuitively say "la WiFi" (feminine).
WiFi is not an acronym for "wireless fidelity"; the developers likely just thought it sounded cool. The term is probably just a play on the words from the audio term "high fidelity". The phrase "Wireless Fidelity" is meaningless.
> 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.
Ok. Why both the homepage and its Github repo doesn't make a single mention of Jason Evans? I know he stepped down but surely it is at least worst mentioning it?
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.
does anyone familiar with the art have thoughts on why only tcmalloc switched from thread caches to cpu caches? would it make linux behavior diverge too much from other platforms?
I think tcmalloc gains on thread churn and oversubscription by going the cpu-cache route on Linux. on other platforms, I am not so sure but that can be offset by say a treiber-stack like setup for cross-thread frees/teardowns. So lesser code for Linux for similar fastpath design I guess.
(Not an expert but ...) unless you pin threads to cores, which is not the default and somewhat awkward in Linux for user applications, having a per-thread cache doesn't really make sense as your thread could be moved to another core and then your cache will no longer be local to the physical cache.
If you use a thread-local data structure, your allocator can pretend that it is running on a single-core, single-task system.
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)
Setting aside whether or not you can pull off a lock free approach here we can be certain of a couple things. There will be at least some overhead that must be paid somewhere even if that's on a separate management thread. And there will be a lot of additional complexity because that's just how concurrency always is.
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.
That's certainly interesting but I don't see how it would change my answer to you. Your question was why projects don't switch. My answer was because doing so seems likely to be a wash at absolute best.
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 the primary thing rseq (ie CPU local data) is good for is obviating the need for atomics (specifically the resultant cache line ping-pong) but thread local data already accomplishes that.
Are you sure you don't just have an axe to grind? Because that is an exceedingly uncommon edge case. Typically you only have a few threads and you aren't inundating the allocator with requests thus it is unlikely to make any practical difference.
Outside of that, TLS has zero overhead and doesn't suffer from contention while rseq involves a small dance and carries a penalty if preempted. I'm certainly open to benchmarks but to me it very much looks like a mixed bag that only comes up when you're already in questionable territory to begin with. If it does come up I'd guess that a handful of threads with contention is a much more common scenario than thousands of threads per physical core and 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.
> Are you sure you don't just have an axe to grind? Because that is an exceedingly uncommon edge case. Typically you only have a few threads and you aren't inundating the allocator with requests thus it is unlikely to make any practical difference.
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.
And that’s not even entirely atypical of any given Rust tokio application (all fs ops are dispatched to a thread pool of effectively unbounded size).
So I totally agree that this is “questionable territory”, but honestly, any application that’s outgrown the basic glibc malloc has made a few mistakes.
That is because you do not need to clear the field at the end of a critical section. It contains the contiguous instruction range where it fires so there is no problem with leaving it active forever unless you have another critical section where you want to use it.
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.
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.
Exactly. You want memory arenas that are hot in this CPU's caches. If your thread moves, its per-thread caches are now elsewhere. Original TCMalloc was developed in the days of 2-4 core servers. Current TCMalloc was an evolution in the context of 32+ core servers.
my feeling is that the space efficiency gains are probably more significant than the reduction in core migration costs. many applications have far more threads than the system has cores.
Don't you just take the current cpuid when you go to access the cache again? Then you mutex and access the per-cpu state. There is a tiny race window but 99.99% of the time you will be hitting the same cpu's cache as you just identified, and there will be ~zero contention.
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.
I use Jemalloc on a project because it has per-thread allocation counters. This lets me not only track what each thread is using, but also restrict workloads by enforcing a memory budget. Since my application is almost completely CPU-bound, I allocate one thread per core and then have some smart scheduling to route requests to the threads. I looked at tcmalloc and mimalloc, and neither had this feature at the time, nor did they seem to have any similar feature that could let me have per-thread heaps, which surprised me.
Nice to see jemalloc active again. The long-term health of the upstream project is probably just as important as the allocator improvements themselves.
82 comments
[ 2.9 ms ] story [ 55.1 ms ] thread- https://news.ycombinator.com/item?id=49715318
Why would the scads of people writing JavaScript, Java, python, go, rails, etc need to be aware of jemalloc?
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 :-).
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 (java heap memory) - had to exclude all possible native libs, 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.
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.)
See e.g. https://github.com/jemalloc/jemalloc/issues/2688
The number of programmers who are in positions to care about jemalloc vs other malloc is minuscule
I wish that wasn't the case, but it is.
This question was not necessary. You know the answer, because people upvoted this.
[0] https://news.ycombinator.com/item?id=44264958
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...
(I also wondered whether systemd had any cultural reference to Système D aka Système Débrouillard), but Pottering does not seem to have a particular taste for jokes ;-)
Source: https://brand.systemd.io/
> 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...
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.
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.
tcmalloc only works on Linux.
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.
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 the primary thing rseq (ie CPU local data) is good for is obviating the need for atomics (specifically the resultant cache line ping-pong) but thread local data already accomplishes that.
maybe we weigh things differently, because:
> 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
Outside of that, TLS has zero overhead and doesn't suffer from contention while rseq involves a small dance and carries a penalty if preempted. I'm certainly open to benchmarks but to me it very much looks like a mixed bag that only comes up when you're already in questionable territory to begin with. If it does come up I'd guess that a handful of threads with contention is a much more common scenario than thousands of threads per physical core and 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.
And that’s not even entirely atypical of any given Rust tokio application (all fs ops are dispatched to a thread pool of effectively unbounded size).
So I totally agree that this is “questionable territory”, but honestly, any application that’s outgrown the basic glibc malloc has made a few mistakes.
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.
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.
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.
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
* https://news.ycombinator.com/item?id=49715318