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).
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.
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 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.
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.
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 …
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 be someone engaging in word play, so probably not.
"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."
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.
ZenoArrow | 3 hours ago
aktenlage | 3 hours ago
charcircuit | 46 minutes ago
ck45 | 3 hours ago
defrost | 3 hours ago
- https://news.ycombinator.com/item?id=49715318
baq | 2 hours ago
rfgplk | 2 hours ago
groomlake | 2 hours ago
HackerThemAll | an hour ago
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.
Pannoniae | an hour ago
matheusmoreira | an hour ago
stackghost | an hour ago
stackghost | an hour ago
Why would the scads of people writing JavaScript, Java, python, go, rails, etc need to be aware of jemalloc?
iam-da-author | an hour ago
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 :-).
xxs | 35 minutes ago
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.
nh2 | 15 minutes ago
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.
imhoguy | an hour ago
adityapatadia | 35 minutes ago
smartmic | 23 minutes ago
gjvc | 21 minutes ago
vocx2tx | 2 hours ago
[0] https://news.ycombinator.com/item?id=44264958
lordnacho | an hour ago
sam_lowry_ | an hour ago
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 be someone engaging in word play, so probably not.
tefkah | 39 minutes ago
eliaspro | 8 minutes ago
Source: https://brand.systemd.io/
simonask | 59 minutes ago
ksec | an hour ago
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.
aktenlage | 53 minutes ago
See the comment of vocx2tx
feldrim | 29 minutes ago
skavi | 32 minutes ago
enduku | 6 minutes ago