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.
>...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.
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.
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.
> Why is this on the HN front page?
This question was not necessary. You know the answer, because people upvoted this.
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.
>...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.
It's just a great memory allocator.
1 reply →
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.
2 replies →
because people like you are too busy whining about it to put up something more interesting