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

61–70 of 259 posts

Re: Meta’s renewed commitment to jemalloc

#61

Post by skavi »

hedora wrote: post #54
skavi wrote: post #47

Earlier quoted context omitted.

We evaluated a few allocators for some of our Linux apps and found (modern) tcmalloc to consistently win in time and space. Our applications are primarily written in Rust and the allocators were linked in statically (except for glibc). Unfortunately I didn't capture much context on the allocation patterns. I think in general the apps allocate and deallocate at a higher rate than most Rust apps (or more than I'd like…

I’m surprised (unless they replaced the core tcmalloc algorithm but kept the name). tcmalloc (thread caching malloc) assumes memory allocations have good thread locality. This is often a double win (less false sharing of cache lines, and most allocations hit thread-local data structures in the allocator). Multithreaded async systems destroy that locality, so it constantly has to run through the exception case: A allo…

modern tcmalloc uses per CPU caches via rseq [0]. We use async rust with multithreaded tokio executors (sometimes multiple in the same application). so relatively high thread counts.

[0]: https://github.com/google/tcmalloc/blob/master/docs/design.m...

Re: Meta’s renewed commitment to jemalloc

#63

Post by hedora »

liuliu wrote: post #45
IshKebab wrote: post #28

Earlier quoted context omitted.

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.

There are, look no further than jemalloc API surface itself: https://jemalloc.net/jemalloc.3.html One thing to call out: sdallocx integrates well with C++'s sized delete semantics: https://isocpp.org/files/papers/n3778.html

You can also play tricks with inlining and constant propagation in C (especially on the malloc path, where the ground-truth allocation size is usually statically known).

Re: Meta’s renewed commitment to jemalloc

#64

Post by skavi »

ComputerGuru wrote: post #57
skavi wrote: post #47

Earlier quoted context omitted.

We evaluated a few allocators for some of our Linux apps and found (modern) tcmalloc to consistently win in time and space. Our applications are primarily written in Rust and the allocators were linked in statically (except for glibc). Unfortunately I didn't capture much context on the allocation patterns. I think in general the apps allocate and deallocate at a higher rate than most Rust apps (or more than I'd like…

That’s a considerable regression for mimalloc between 2.1 and 2.2 – did you track it down or report it upstream? Edit: I see mimalloc v3 is out – I missed that! That probably moots this discussion altogether.

nope.

Re: Meta’s renewed commitment to jemalloc

#65

Post by Aurornis »

markstos wrote: post #10

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

Jason Evans worked for Facebook for almost two decades, starting in 2009 - https://jasone.github.io/2025/06/12/jemalloc-postmortem/

He's doing just fine. If you're looking for a story about a FAANG company not paying engineers well for their work, this isn't it.

Re: Meta’s renewed commitment to jemalloc

#66

Post by jjuliano »

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.

Re: Meta’s renewed commitment to jemalloc

#67

Post by jeffbee »

bmenrigh wrote: post #37
jeffbee wrote: post #27

Earlier quoted context omitted.

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 th…

Right but on Intel the 1G page size has historically been the odd one. For example Skylake-X has 1536 L2 shared TLB entries for either 4K or 2M pages, but it only has 16 entries that can be used for 1G pages. It wasn't unified until Cascade Lake. But Skylake-like Xeon is still incredibly common in the cloud so it's hard to target the later ones.

Re: Meta’s renewed commitment to jemalloc

#68

Post by m463 »

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 the lowly malloc probably has lots of interesting ways of growing and changing.

Re: Meta’s renewed commitment to jemalloc

#69

Post by cogman10 »

xxs wrote: post #49
NooneAtAll3 wrote: post #44

Earlier quoted context omitted.

doesn't java also? I heard that was a common complaint for minecraft

What do you mean - if Java returns memory to the OS? Which one - Java heap of the malloc/free by the JVM?

Java is pretty greedy with the memory it claims. Especially historically it was pretty hard to get the JVM to release memory back to the OS.

To an outsider, that looks like the JVM heap just steadily growing, which is easy to mistake for a memory leak.

Post reply on HN