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

131–140 of 259 posts

Re: Meta’s renewed commitment to jemalloc

#131

Post by cogman10 »

snackbroken wrote: post #125
adgjlsfhk1 wrote: post #91

Earlier quoted context omitted.

This only really ends up being a problem on windows. On systems with proper virtual memory setups, the cost of unused memory is very low (since the the OS can just page it out)

For video games it is pretty bad, because reading back a page from disk containing "freed" (from the application perspective, but not returned to the OS) junk you don't care about is significantly slower than the OS just handing you a fresh one. A 10-20ms delay is a noticeable stutter and even on an SSD that's only a handful of round-trips.

Games today should be using ZGC.

There's a lot of bad tuning guides for minecraft that should be completely ignored and thrown in the trash. The only GC setting you need for it is `-XX:+UseZGC`

For example, a number of the minecraft golden guides I've seen will suggest things like setting pause targets but also survivor space sizes. The thing is, the pause target is disabled when you start playing with survivor space sizes.

Re: Meta’s renewed commitment to jemalloc

#132

Post by apatheticonion »

ajxs wrote: post #121
apatheticonion wrote: post #117

As an Australian who was just made redundant from a role that involved this type of low level programming - I love working on these these kinds of challenges. I'm saddened that the job market in Australia is largely React CRUD applications and that it's unlikely I will find a role that lets me leverage my niche skill set (which is also my hobby)

Speaking as an Australian that works on React CRUD applications because there's nothing else in the market, I've been reading through this thread thinking the exact same thing.

Google had some position open working on the kernel for ChromeOS, and Microsoft had some positions working on data center network drivers.

I applied for both and got ghosted, haha.

I also saw a government role as a security researcher. Involves reverse engineering, ghidra and that sort of thing. Super awesome - but the pay is extremely uncompetitive. Such a shame.

Other than that, the most interesting roles are in finance (like HFT) - where you need to juggle memory allocations, threads and use C++ (hoping I can pitch Rust but unlikely).

Sadly they have a reputation of having pretty rough cultures, uncompetitive salaries and it's all in-office

Re: Meta’s renewed commitment to jemalloc

#133

Post by gzread »

apatheticonion wrote: post #117

As an Australian who was just made redundant from a role that involved this type of low level programming - I love working on these these kinds of challenges. I'm saddened that the job market in Australia is largely React CRUD applications and that it's unlikely I will find a role that lets me leverage my niche skill set (which is also my hobby)

I have a relative in Australia who was hired by some type of consultancy to work on Samba, but I don't know what work he was doing.

Re: Meta’s renewed commitment to jemalloc

#134

Post by gzread »

alex1138 wrote: post #97
bluGill wrote: post #60

Earlier quoted context omitted.

Facebook had talks already years ago (10+) - nobody was allowed to share real numbers, but several facebook employed where allowed to share that the company has measured savings from optimizations. Reading between the lines, a 0.1% efficiency improvement to some parts of Facebook would save them $100,000 a month (again real numbers were never publicly shared so there is a range - it can't be less than $20,000), and s…

I've heard of some people getting banned from FB to save memory space? Surely that can't be the case but I swear I've seen something like that

There are some people who think they can beat the system by treating apps like Telegram and Discord as free cloud storage, and they certainly get banned to save storage space.

Re: Meta’s renewed commitment to jemalloc

#135

Post by jeffbee »

ComputerGuru wrote: post #73
codexon wrote: post #51

Earlier quoted context omitted.

I've benchmarked them every few years, they never seem to differ by more than a few percent, and jemalloc seems to fragment and leak the least for processes running for months. Mimalloc made the claim that they were the fastest/best when they released and that didn't hold up to real world testing, so I am not inclined to trust it now.

> Mimalloc made the claim that they were the fastest/best when they released and that didn't hold up to real world testing That’s… ahistorical, at least so far as I remember. It wasn’t marketed as either of those; it was marketed as small/simple/consistent with an opt-in high-severity mode, and then its performance bore out as a result of the first set of target features/design goals. It was mainly pushed as easy to…

mimalloc definitely made claims that could not be reproduced, or at least not by me. That's why I wrote this doc five years ago. "Irreproducible malloc benchmarks" https://www.dropbox.com/scl/fi/evnn6yoornh9p6l7nq1t9/Irrepro...

Re: Meta’s renewed commitment to jemalloc

#136

Post by amacneil »

apatheticonion wrote: post #117

As an Australian who was just made redundant from a role that involved this type of low level programming - I love working on these these kinds of challenges. I'm saddened that the job market in Australia is largely React CRUD applications and that it's unlikely I will find a role that lets me leverage my niche skill set (which is also my hobby)

I know this isn’t who’s hiring thread, but we are hiring in AU for low-level data processing and have interesting performance challenges.

Link in bio.

Re: Meta’s renewed commitment to jemalloc

#137

Post by larsberg »

flykespice wrote: post #30

Jemalloc also is used by android bionic libc library

scudo has been the default allocator for Android since Android 11, and we are hoping to make it mandatory for the few remaining places that don't use it. Using an allocator without memory protections in 2026 (especially after we have closed nearly all known performance gaps with jemalloc) is really not a great choice.

Re: Meta’s renewed commitment to jemalloc

#138

Post by jcalvinowens »

adsharma wrote: post #72

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

I'm really surprised to see you still hocking this.

We did extensive benchmarking of HHVM with and without your patches, and they were proven to make no statistically significant difference in high level metrics. So we dropped them out of the kernel, and they never went back in.

I don't doubt for a second you can come up with specific counterexamples and microbenchnarks which show benefit. But you were unable to show an advantage at the system level when challenged on it, and that's what matters.

Re: Meta’s renewed commitment to jemalloc

#139

Post by [deleted] »

apatheticonion wrote: post #132
ajxs wrote: post #121

Earlier quoted context omitted.

Speaking as an Australian that works on React CRUD applications because there's nothing else in the market, I've been reading through this thread thinking the exact same thing.

Google had some position open working on the kernel for ChromeOS, and Microsoft had some positions working on data center network drivers. I applied for both and got ghosted, haha. I also saw a government role as a security researcher. Involves reverse engineering, ghidra and that sort of thing. Super awesome - but the pay is extremely uncompetitive. Such a shame. Other than that, the most interesting roles are in fi…

[deleted]

Re: Meta’s renewed commitment to jemalloc

#140

Post by asveikau »

adsharma wrote: post #72

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

Maybe I'm misreading, but considering it OK to leak memory contents across a process boundary because it's within a cgroup sounds wild.
Post reply on HN