Meta’s renewed commitment to jemalloc • Hacker News Board

Re: Meta’s renewed commitment to jemalloc

#81

Post by joelsiks » Mon, Mar 16, 2026, 8:14 PM UTC

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

Re: Meta’s renewed commitment to jemalloc

#82

Post by rishabhjajoriya » Mon, Mar 16, 2026, 8:23 PM UTC

Large engineering orgs often underestimate how much CI pipelines amplify performance issues. Even small inefficiencies multiply when builds run hundreds of times a day.

Re: Meta’s renewed commitment to jemalloc

#83

Post by jshorty » Mon, Mar 16, 2026, 8:27 PM UTC

Surprised not to see any mention of the global memory supply shock. Would love to learn more about how that economic is shifting software priorities toward memory allocation for the first time in my (relatively young) career

Re: Meta’s renewed commitment to jemalloc

#84

Post by yxhuvud » Mon, Mar 16, 2026, 8:27 PM UTC

xxs wrote: post #34

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.

If you changed from glibc to jemalloc and that solved your issues, then you should blame glibc, not the JVM.

Re: Meta’s renewed commitment to jemalloc

#85

Post by [deleted] » Mon, Mar 16, 2026, 8:29 PM UTC

jshorty wrote: post #83

Surprised not to see any mention of the global memory supply shock. Would love to learn more about how that economic is shifting software priorities toward memory allocation for the first time in my (relatively young) career

[deleted]

Re: Meta’s renewed commitment to jemalloc

#86

Post by VoidWarranty » Mon, Mar 16, 2026, 8:33 PM UTC

OsrsNeedsf2P wrote: post #53

fermentation wrote: post #5

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

I work in the space. This article would not have been published if the team responsible was on the chopping block

[dead]

Re: Meta’s renewed commitment to jemalloc

#87

Post by [deleted] » Mon, Mar 16, 2026, 8:36 PM UTC

[deleted]

Re: Meta’s renewed commitment to jemalloc

#88

Post by m3kw9 » Mon, Mar 16, 2026, 8:36 PM UTC

All the AI investment and their biggest news is commitment to Jemalloc

Re: Meta’s renewed commitment to jemalloc

#89

Post by jra_samba » Mon, Mar 16, 2026, 8:42 PM UTC

m463 wrote: post #68

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 remember in the early days of web services, using the apache portable runtime, specifically memory pools. If you got a web request, you could allocate a memory pool for it, then you would do all your memory allocations from that pool. And when your web request ended - either cleanly or with a hundred different kinds of errors, you could just free the entire pool. it was nice and made an impression on me. I think th…

Look into talloc, used inside Samba (and other FLOSS projects like sssd). Exactly this.

Re: Meta’s renewed commitment to jemalloc

#90

Post by celdon25 » Mon, Mar 16, 2026, 8:43 PM UTC

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

With the reputation of that company, one can wonder a lot of backstories that are even more depressing than a memory shortage.