Hacker News

> We plan to deliver improvements to [..] purging mechanisms

During my time at Facebook, I maintained a bunch of kernel patches to improve jemalloc purging mechanisms. It wasn't popular in the kernel or the security community, but it was more efficient on benchmarks for sure.

Many programs run multiple threads, allocate in one and free in the other. Jemalloc's primary mechanism used to be: madvise the page back to the kernel and then have it allocate it in another thread's pool.

One problem: this involves zero'ing memory, which has an impact on cache locality and over all app performance. It's completely unnecessary if the page is being recirculated within the same security domain.

The problem was getting everyone to agree on what that security domain is, even if the mechanism was opt-in.

https://marc.info/?l=linux-kernel&m=132691299630179&w=2

I recently started using Microsoft's mimalloc (via an LD_PRELOAD) to better use huge (1 GB) pages in a memory intensive program. The performance gains are significant (around 20%). It feels rather strange using an open source MS library for performance on my Linux system.

There needs to be more competition in the malloc space. Between various huge page sizes and transparent huge pages, there are a lot of gains to be had over what you get from a default GNU libc.

One has to wonder if this due to the global memory shortage. ("Oh - changing our memory allocator to be more efficient will yield $XXM dollar savings over the next year").

Related. Others?

Jemalloc Postmortem - https://news.ycombinator.com/item?id=44264958 - June 2025 (233 comments)

Jemalloc Repositories Are Archived - https://news.ycombinator.com/item?id=44161128 - June 2025 (7 comments)

Opening up strong with a gigantic merge of the stuff they've been working on in their own fork: https://github.com/jemalloc/jemalloc/pull/2863

> I knew from hard experience with Darwin that internally siloed open source projects cannot thrive (HHVM was a repeat lesson)

I'm glad HHVM happened, and also glad it stalled. I don't think PHP 7 and 8 would've made the improvements they did without HHVM kicking their ass, and I think there would've been a fork based on HHVM rather than PHP 8 if HHVM hadn't lost that public momentum.

I remember Wikimedia's testing/partial implementation of HHVM[1] being a turning point, at least in the circles I was in at the time. It showed PHP performance could actually be improved, and by quite a lot. Without that proof of concept at that scale _in the open_, HHVM devs could've ran benchmarks from here to eternity and people still would've said, "yeah, sure, _if you're Facebook_"

1: https://techblog.wikimedia.org/2014/12/29/how-we-made-editin...

I remember I was a senior lead softeng of a worldbank funded startup project, and have deployed Ruby with jemalloc in prod. There's a huge noticeable speed and memory efficiency. It did saved us a lot of AWS costs, compare to just using normal Ruby. This was 8 years ago, why haven't projects adopt it yet as de facto.

I used jemalloc recently for ComfyUI/Wan and it’s literally magic. I’m surprised it doesn’t come that way by default.

Is there a concise timelime/history of this? I thought jemalloc was 100% open source, why is Meta in control of it?

Someone should tell Bryan Cantrill, he'd probably be ecstatic...

First impressions: LOL, the blunt commentary in the HN thread title compared to the PR-speak of the fb.com post.

Second thoughts: Actually the fb.com post is more transparent than I'd have predicted. Not bad at all. Of course it helps that they're delivering good news!

Few months back, some of the services switched to jemalloc for the Java VM. It took months (of memory dumps and tracing sys-calls) to blame the JVM, itself, for getting killed by the oom_killer.

Initially the idea was diagnostics, instead the the problem disappeared on its own.

>We are committed to continuing to develop jemalloc development

From the Department of Redundancy Department.

How is the original author making out in the new arrangement?

Jemalloc is used by android bionic libc library

Meta never abandoned jemalloc. https://github.com/facebook/jemalloc remained public the entire time. It's my understanding that Jason Evans, the creator of jemalloc, had ownership over the jemalloc/jemalloc repo which is why that one stopped being updated after he left.

Seems like they’d want to wait to commit until after the layoffs, right?

[dead]

[dead]

[dead]

And the Oscar for most mealy-mouthed post of the year goes to…