by jasone on 6/13/25, 1:37 AM with 233 comments
by Svetlitski on 6/13/25, 3:35 AM
I’ve been meaning to ask Qi if he’d be open to cutting a final 6.0 release on the repo before re-archiving.
At the same time it’d be nice to modernize the default settings for the final release. Disabling the (somewhat confusingly backwardly-named) “cache oblivious” setting by default so that the 16 KiB size-class isn’t bloated to 20 KiB would be a major improvement. This isn’t to disparage your (i.e. Jason’s) original choice here; IIRC when I last talked to Qi and David about this they made the point that at the time you chose this default, typical TLB associativity was much lower than it is now. On a similar note, increasing the default “page size” from 4 KiB to something larger (probably 16 KiB), which would correspondingly increase the large size-class cutoff (i.e. the point at which the allocator switches from placing multiple allocations onto a slab, to backing individual allocations with their own extent directly) from 16 KiB up to 64 KiB would be pretty impactful. One of the last things I looked at before leaving Meta was making this change internally for major services, as it was worth a several percent CPU improvement (at the cost of a minor increase in RAM usage due to increased fragmentation). There’s a few other things I’d tweak (e.g. switching the default setting of metadata_thp from “disabled” to “auto”, changing the extent-sizing for slabs from using the nearest exact multiple of the page size that fits the size-class to instead allowing ~1% guaranteed wasted space in exchange for reducing fragmentation), but the aforementioned settings are the biggest ones.
by adityapatadia on 6/13/25, 6:56 AM
One fine day, we discovered Jemalloc and put it in our service, which was causing a lot of memory fragmentation. We did not think that those 2 lines of changes in Dockerfile were going to fix all of our woes, but we were pleasantly surprised. Every single issue went away.
Today, our multi-million dollar revenue company is using your memory allocator on every single service and on every single Dockerfile.
Thank you! From the bottom of our hearts!
by masklinn on 6/13/25, 5:14 AM
FWIW while it was a factor it was just one of a number: https://github.com/rust-lang/rust/issues/36963#issuecomment-...
And jemalloc was only removed two years after that issue was opened: https://github.com/rust-lang/rust/pull/55238
by dazzawazza on 6/13/25, 10:40 AM
I learned of it from it's integration in FreeBSD and never looked back.
jemalloc has help entertained a lot of people :)
by chubot on 6/13/25, 2:51 AM
Or I wonder if they could simply use tcmalloc or another allocator these days?
Facebook infrastructure engineering reduced investment in core technology, instead emphasizing return on investment.
by schrep on 6/13/25, 5:39 AM
by kstrauser on 6/13/25, 2:54 AM
by meisel on 6/13/25, 2:51 AM
by wiz21c on 6/13/25, 7:51 AM
> And people find themselves in impossible situations where the main choices are 1) make poor decisions under extreme pressure, 2) comply under extreme pressure, or 3) get routed around.
It doesn't sound like a work place :-(
by Twirrim on 6/13/25, 1:58 AM
by jeffbee on 6/13/25, 1:59 AM
by the_mitsuhiko on 6/13/25, 9:36 AM
So the flow is like this: user has an allocation looking issue. Picks up $allocator. If they have an $allocator type problem then they keep using it, otherwise they use something else.
There are tons of users if these allocators but many rarely engage with the developers. Many wouldn’t even notice improvements or regressions on upgrades because after the initial choice they stop looking.
I’m not sure how to fix that, but this is not healthy for such projects.
by mavis on 6/13/25, 3:36 AM
by didip on 6/13/25, 2:16 PM
jemalloc is always the first thing I installed whenever I had to provision bare servers.
If jemalloc is somehow the default allocator in Linux, I think it will not have a hard time retaining contributors.
by mrweasel on 6/13/25, 11:49 AM
I'm not really sure what I expected, but somehow I expect a memory allocator to be ... smaller, simpler perhaps?
by gdiamos on 6/13/25, 1:49 AM
by soulbadguy on 6/13/25, 8:33 PM
by p0w3n3d on 6/13/25, 4:34 AM
I wonder if you did get everything you should from the companies that use it. I mean sometimes I feel that big tech firms only use free software, never giving anything to it, so I hope you were the exception here.
by burnt-resistor on 6/13/25, 12:01 PM
by nevon on 6/13/25, 2:48 AM
by poorman on 6/13/25, 2:31 AM
by dikei on 6/13/25, 3:04 AM
Good times.
by brcmthrowaway on 6/13/25, 7:40 AM
by skeptrune on 6/13/25, 2:59 AM
by userbinator on 6/13/25, 3:28 AM
by Omarbev on 6/13/25, 6:32 AM