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

21–30 of 259 posts

Re: Meta’s renewed commitment to jemalloc

#21

Post by codexon »

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.

Re: Meta’s renewed commitment to jemalloc

#22

Post by masklinn »

RegnisGnaw wrote: post #19

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

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

Re: Meta’s renewed commitment to jemalloc

#23

Post by echelon »

RegnisGnaw wrote: post #19

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

If you filter the commits to the past five years, four of the top six committers are Meta employees. The other two might be as well, it just doesn't say that on their Github / personal website.

Re: Meta’s renewed commitment to jemalloc

#24

Post by hrmtst93837 »

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.

[flagged]

Re: Meta’s renewed commitment to jemalloc

#25

Post by Cloudef »

sylware wrote: post #12
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…

If there is so much performance difference among generic allocators, it means you need semantic optimized allocators (unless performance is actually not that much important in the end).

You are not wrong and this is indeed what zig is trying to push by making all std functions that allocate take a allocator parameter.

Re: Meta’s renewed commitment to jemalloc

#26

Post by kstrauser »

charcircuit wrote: post #16
kstrauser wrote: post #15

Earlier quoted context omitted.

The repo's availability isn't related to whether it's still maintained.

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.

Re: Meta’s renewed commitment to jemalloc

#27

Post by jeffbee »

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.

Re: Meta’s renewed commitment to jemalloc

#28

Post by IshKebab »

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 feel like the real thing that needs to change is we need a more expressive allocation interface than just malloc/realloc. I'm sure that memory allocators could do a significantly better job if they had more information about what the program was intending to do.

Re: Meta’s renewed commitment to jemalloc

#29

Post by vintermann »

masklinn wrote: post #22
RegnisGnaw wrote: post #19

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

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.

Post reply on HN