Back

Jemalloc 5.4.0

49 points4 hoursgithub.com
vocx2tx2 hours ago

For some context on why this release is notable: Jemalloc Postmortem [0]

[0] https://news.ycombinator.com/item?id=44264958

ZenoArrow3 hours ago

Why is this on the HN front page? Is there something particularly noteworthy about this release?

aktenlage3 hours ago

They resumed development on jemalloc only recently, after years of no releases.

defrost2 hours ago

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

ck452 hours ago

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

baq2 hours ago

jemalloc is something you should be aware of if you do software for a living

rfgplk2 hours ago

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).

groomlake1 hour ago

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.

HackerThemAll1 hour ago

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.