> 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.
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).
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.
"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."
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” :)
That's the rule the old geezers at the Academy insist on. But then you have idiotic situations where everyone is using "le" for e.g. the COVID virus, while Academicians cry about the D meaning "Disease", which is feminine, making it "la COVID" in their book. As for all languages, the most important rule is that usage prevails. And that's something we in France still have a hard time integrating into public discourse.
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).
If you keep your access point secure and in good working order, or if you can flash any firmware into OpenWRT... make sure to publicly credit your excellent "Wi-fu"
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?
(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.
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.
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 …
Development was never stopped for jemalloc. This is a common misconception. There just were not releases being tagged and packaged against the ongoing development.
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?
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.
>...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 (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.
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.
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.
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 :-).
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).
I'd happily see performance, latency and stability of your allocators in massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects.
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.
You're correct, but his point is that you don't need to solve the generic problem. Solving the generic problem is very hard. Grug doesn't like solving hard problem. What does grug do? Solve five easy problems. Make an arena for the short-lived objects, reuse the objects, use generic multithreaded malloc for the rest. Grug happy.
I guess the point was that before you consider using a different allocator you should rule out a custom one.
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.
>massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects.
My first thought would be to use per thread pool allocators.
For some context on why this release is notable: Jemalloc Postmortem [0]
[0] https://news.ycombinator.com/item?id=44264958
> 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.
And some additional context from a few months ago, building off the postmortem.
https://theconsensus.dev/p/2026/04/16/who-even-uses-jemalloc...
I always wondered, is it French? "Je m'alloc du memory"
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).
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.
It does
> 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...
damn i always thought it was a french thing, this is blowing my mind
"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."
Source: https://brand.systemd.io/
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” :)
That's the rule the old geezers at the Academy insist on. But then you have idiotic situations where everyone is using "le" for e.g. the COVID virus, while Academicians cry about the D meaning "Disease", which is feminine, making it "la COVID" in their book. As for all languages, the most important rule is that usage prevails. And that's something we in France still have a hard time integrating into public discourse.
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).
If you keep your access point secure and in good working order, or if you can flash any firmware into OpenWRT... make sure to publicly credit your excellent "Wi-fu"
Better keep the wifi working, or your waifu could get angry.
Thanks, now my brain will forever read it like that. I'm not even a little bit French.
Memory je Srbia
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.
> Just wish we have a little bit of context
See the comment of vocx2tx
> See the comment of vocx2tx
https://news.ycombinator.com/item?id=49750698
To:
* https://news.ycombinator.com/item?id=44264958
* https://jasone.github.io/2025/06/12/jemalloc-postmortem/
It's only mentioned in history: https://github.com/jemalloc/jemalloc/wiki/Background#history
I switched to jemalloc on a sidekiq queue and memory dropped from 8gib to under 1gib
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://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
Related, from three days ago, "Comparison of Malloc() Algorithms":
* https://news.ycombinator.com/item?id=49715318
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?
(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.
i think we agree that per cpu caching seems superior. i’m looking for the other side of this. most allocators seem to have stuck with per thread.
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)
https://google.github.io/tcmalloc/rseq.html
i don’t believe rseq based cpu local caches require memory barriers on the fast path.
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.
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.
Why is this on the HN front page? Is there something particularly noteworthy about this release?
I upvoted it because I benefit from jemalloc in my stack (RoR) and I am tired of AI taking over HN front page. Let the hacker spirit be back!
Upvoted for the same reason. We would not be able to run our workloads without Jemalloc. Kudos to this awesome piece of software.
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 …
They resumed development on jemalloc only recently, after years of no releases.
Development was never stopped for jemalloc. This is a common misconception. There just were not releases being tagged and packaged against the ongoing development.
The noted resumption and likely a small amount of halo effect from the Comparison of Malloc() Algorithms thread two / three days ago.
- https://news.ycombinator.com/item?id=49715318
I just checked whether it's the first release after Jason Evans stepped down as maintainer, but it isn't. That was the previous release, 5.3.1
jemalloc is something you should be aware of if you do software for a living
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?
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.
>...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 (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'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.
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.
I wish that wasn't the case, but it is.
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 :-).
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).
Your experience writing memory allocators is irrelevant. The point is that jemalloc is widely used and that’s why it makes sense to be aware of it.
Writing an allocator is simple, you’re correct, but writing an allocator that doesn’t suck is not simple.
I'd happily see performance, latency and stability of your allocators in massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects.
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.
You're correct, but his point is that you don't need to solve the generic problem. Solving the generic problem is very hard. Grug doesn't like solving hard problem. What does grug do? Solve five easy problems. Make an arena for the short-lived objects, reuse the objects, use generic multithreaded malloc for the rest. Grug happy.
I guess the point was that before you consider using a different allocator you should rule out a custom one.
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.
>massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects.
My first thought would be to use per thread pool allocators.
>where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects.
Should one even want a global, general purpose heap allocator for that? Seems like a crazy idea to even consider.
Not everything needs to be general purpose. Allocation can be as easy as bumping a pointer, and it's hard to beat that.
> Why is this on the HN front page?
This question was not necessary. You know the answer, because people upvoted this.
because people like you are too busy whining about it to put up something more interesting