This is a good thing
Jemalloc Postmortem
81–90 of 250 posts
Re: Jemalloc Postmortem
#82Earlier quoted context omitted.
As far as I know there is no technical reason why jemalloc shouldn't be the default allocator. In fact, as pointed out in the article, it IS the default allocator on FreeBSD. My understanding is it is largely political.
Now that I think about it, I could easily imagine it being left out of glibc because it doesn't build on Hurd or something.
> I could easily imagine it being left out of glibc because [...]
... its license is BSD-2-Clause ;)
hence "political"
Re: Jemalloc Postmortem
#83Oh that's interesting. jemalloc is the memory allocator used by redis, among other projects. Wonder what the performance impact will be if they have to change allocators.
I know through years of looking at Ruby on Rails performance a commonly cited quick win was to run with jemalloc.
Re: Jemalloc Postmortem
#84Jason, here is a story about how much your work impacts us.
We run a decently sized company that processes hundreds of millions of images/videos per day. When we first started about 5 years ago, we spent countless hours debugging issues related to memory fragmentation.
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!
Re: Jemalloc Postmortem
#85Earlier quoted context omitted.
Now that I think about it, I could easily imagine it being left out of glibc because it doesn't build on Hurd or something.
> I could easily imagine it being left out of glibc because [...] ... its license is BSD-2-Clause ;) hence "political"
Huh? Bsd-style licenses are fully compatible with gpl.
The problem is exactly this: Facebook becomes the upstream of a key part of your system.
And Facebook can just walk away from the project. Like it did just now.
Re: Jemalloc Postmortem
#86I’ve wondered about this before but never when around people who might know. From my outsider view, jemalloc looked like a strict improvement over glibc’s malloc, according to all the benchmarks I’d seen when the subject came up. So, why isn’t it the default allocator?
For a long time, one of the major problems with alternate allocators is that they would never return free memory back to the OS, just keep the dirty pages in the process. This did eventually change, but it remains a strong indicator of different priorities. There's also the fact that ... a lot of processes only ever have a single thread, or at most have a few background threads that do very little of interest. So all…
> Semi-related: one thing that most people never think about: it is exactly the same amount of work for the kernel to zero a page of memory (in preparation for a future mmap) as for a userland process to zero it out (for its own internal reuse)
Possibly more work since the kernel can't use SIMD
Re: Jemalloc Postmortem
#87Earlier quoted context omitted.
> I could easily imagine it being left out of glibc because [...] ... its license is BSD-2-Clause ;) hence "political"
Huh? Bsd-style licenses are fully compatible with gpl. The problem is exactly this: Facebook becomes the upstream of a key part of your system. And Facebook can just walk away from the project. Like it did just now.
They are compatible but that's not the point.
If it were included it would instantly become a LGPL hard-fork because of any subsequently added line of code, if not by "virality" of the glibc license, at least because any glibc author code addition would be LGPL, per GNU project policy/ideology.
Also also this would he a hard bar to pass: https://sourceware.org/glibc/wiki/CopyrightFSForDisclaim
As I recall this is what prevented Apple from contributing C blocks† back to upstream GCC.
Re: Jemalloc Postmortem
#88Earlier quoted context omitted.
Disclaimer: I'm not an allocator engineer, this is just an anecdote. A while back, I had a conversation with an engineer who maintained an OS allocator, and their claim was that custom allocators tend to make one process's memory allocation faster at the expense of the rest of the system. System allocators are less able to make allocation fair holistically, because one process isn't following the same patterns as the…
I don't think that's really a position that can be defended. Both jemalloc and tcmalloc evolved and were refined in antagonistic multitenant environments without one overwhelming application. They are optimal for that exact thing.
> Both jemalloc and tcmalloc evolved and were refined in antagonistic multitenant environments without one overwhelming application. They are optimal for that exact thing.
They were mostly optimised on Facebook/Google server-side systems, which were likely one application per VM, no? (Unlike desktop usage where users want several applications to run cooperatively). Firefox is a different case but apparently mainline jemalloc never matched Firefox jemalloc, and even then it's entirely plausible that Firefox benefitted from a "selfish" allocator.
Re: Jemalloc Postmortem
#89[dead]
Re: Jemalloc Postmortem
#90What allocator does Apple use?