Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meta’s renewed commitment to jemalloc

engineering.fb.com

Post reply on HN
Print view View original

31–40 of 259 posts

Re: Meta’s renewed commitment to jemalloc

#31

Post by masklinn »

kstrauser wrote: post #26
charcircuit wrote: post #16

Earlier quoted context omitted.

Meta still maintained it and actively pushed commits to it fixing bugs and adding improvements. From this blog post it sounds like they are increasing investment into it along with resurrecting the original repo. When the repo was archived Meta said that development on jemalloc would be focused towards Meta's own goals and needs as opposed to the larger ecosystem.

I'm not directly involved enough to dig into the details here, but facebook/jemalloc currently says: > This branch is 71 commits ahead of and 70 commits behind jemalloc/jemalloc:dev. It looks like both have been independently updated.

The team probably sync'd the two after unarchiving the original.

Re: Meta’s renewed commitment to jemalloc

#32

Post by codexon »

hrmtst93837 wrote: post #24
codexon wrote: post #21

Earlier quoted context omitted.

I've been using jemalloc for over 10 years and don't really see a need for it to be updated. It always holds up in benchmarks against any new flavor of the month malloc that comes out. Last time I checked mimalloc which was admittedly a while ago, probably 5 years, it was noticebly worse and I saw a lot of people on their github issues agreeing with me so I just never looked at it again.

[flagged]

It still beat mimalloc when I checked 4-5 years ago.

Re: Meta’s renewed commitment to jemalloc

#33

Post by augusto-moura »

bfgeek wrote: post #11

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

Not just shortage, any improvements to LLMs/electricity/servers memory footprint is becoming much more valuable as the time goes. If we can get 10% faster, you can easily get a lead in the LLM race. The incentives to transparently improving performance are tremendous

Re: Meta’s renewed commitment to jemalloc

#34

Post by xxs »

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.

Re: Meta’s renewed commitment to jemalloc

#35

Post by anthk »

bmenrigh wrote: post #8

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…

I used mimalloc to run zenlisp under OpenBSD as it would clash with the paranoid malloc of base.

Re: Meta’s renewed commitment to jemalloc

#36

Post by nevdka »

pjmlp wrote: post #20
adgjlsfhk1 wrote: post #13

Earlier quoted context omitted.

One of the best parts about GC languages is they tend to have much more efficient allocation/freeing because the cost is much more lumped together so it shows up better in a profile.

Agreed, however there is also a reason why the best ones also pack multiple GC algorithms, like in Java and .NET, because one approach doesn't fit all workloads.

Then there’s perl, which doesn’t free at all.

Re: Meta’s renewed commitment to jemalloc

#37

Post by bmenrigh »

jeffbee wrote: post #27
bmenrigh wrote: post #8

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…

Just out of curiosity are you getting 1GB huge pages on Xeon or some other platform? I always thought this class of page is the hardest to exploit, considering that the machine only has, if I recall correctly, one TLB slot for those.

Modern x86_64 has supported multiple page sizes for a long time. I'm on commodity Zen 5 hardware (9900X) with 128 GiB of RAM. Linux will still use a base page size of 4kb but also supports both 2 MiB and 1 GiB huge pages. You can pass something like `default_hugepagesz=2M hugepagesz=1G hugepages=16` to your kernel on boot to use 2 MiB pages but reserve 16 1 GiB pages for later use.

The nice thing about mimalloc is that there are a ton of configurable knobs available via env vars. I'm able to hand those 16 1 GiB pages to the program at launch via `MIMALLOC_RESERVE_HUGE_OS_PAGES=16`.

EDIT: after re-reading your comment a few times, I apologize if you already knew this (which it sounds like you did).

Re: Meta’s renewed commitment to jemalloc

#38

Post by adgjlsfhk1 »

codexon wrote: post #21
bmenrigh wrote: post #8

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…

I've been using jemalloc for over 10 years and don't really see a need for it to be updated. It always holds up in benchmarks against any new flavor of the month malloc that comes out. Last time I checked mimalloc which was admittedly a while ago, probably 5 years, it was noticebly worse and I saw a lot of people on their github issues agreeing with me so I just never looked at it again.

Mimalloc v3 has just come out (about a month ago) and is a significant improvement over both v2 and v1 (what you likely last tested)

Re: Meta’s renewed commitment to jemalloc

#39

Post by xxs »

vintermann wrote: post #29
masklinn wrote: post #22

Earlier quoted context omitted.

Jason Evans (the creator of jemalloc) recounted the entire thing last year: https://jasone.github.io/2025/06/12/jemalloc-postmortem/

"Were I to reengage, the first step would be at least hundreds of hours of refactoring to pay off accrued technical debt." Facebook's coding AIs to the rescue, maybe? I wonder how good all these "agentic" AIs are at dreaded refactoring jobs like these.

Refactor doesn't mean just artificial puff-up jobs, it's very likely internal changes and reorganization (hence 100s of hours).

There are not many engineers capable of working on memory allocators, so adding more burden by agentic stuff is unlikely to produce anything of value.

Re: Meta’s renewed commitment to jemalloc

#40

Post by runevault »

bfgeek wrote: post #11

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

On top of cost, they probably cannot get as much memory as they order in a timely fashion so offsetting that with greater efficiency matters right now.
Post reply on HN