5 ms·

I’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 mallo

I’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?

sanxiyn 1y ago
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.
- kstrauser 1y ago
  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.
  - lloeki 1y ago
    > I could easily imagine it being left out of glibc because [...] ... its license is BSD-2-Clause ;) hence "political"
    - vkazanov 1y ago
      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.
      - lloeki 1y ago
        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 https://sourceware.org/glibc/wiki/CopyrightFSForDisclaim As I recall this is what prevented Apple from contributing C blocks† back to upstream GCC. † https://github.com/lloeki/cblocks-clobj https://github.com/lloeki/cblocks-clobj
        vkazanov 1y ago
        What prevents apple from working with gpl-style licenses is strict hatred towards code that they can't use without opensourcing it. So this is what prevents them from contributing to gpl projects: the need to control access to code. Llvm is OK for them from this point of view: upstream is open but they can maintain and distribute their proprietary fork.
        lloeki 1y ago
        > What prevents apple from working with gpl-style licenses is strict hatred towards code that they can't use without opensourcing it. Specifically regarding the C blocks feature introduced in Snow Leopard, as I recall, Apple wrote implementations for both clang and gcc, attempted to upstream the gcc patchset, said gcc patchset was obviously under a GPL license, but the GCC team threw a fit because it wanted the code copyright to be attributed to the FSF, and that ended up as a stalemate. If there was any hatred they could literally have skipped the whole gcc implementation + patchset upstreaming attempt altogether. Also they did have patchsets of various sizes on other projects, whose code ends up obviously being GPL as well. The "hatred" came later with the GPLv3 family and the patent clause, which is a legal landmine, the FSF stating that signing apps is incompatible with the GPLv3, and getting hung up on copyright transfer. From https://lwn.net/Articles/405417/ https://lwn.net/Articles/405417/ > Apple's motives may not be pure, but it has published the code under the license required and it's the FSF's own copyright assignment policies that block the inclusion. The code is available and licensed appropriately for the version of GCC that Apple adopted. It might be nice if Apple took the further step of assigning copyright to the FSF, but the GPLv3 was not part of the bargain that Apple agreed to when it first started contributing to GCC. The intent behind such copyright transfer is generally so that the recipient of the transfer can relicense without having to ask all contributors. Essentially as a contributor agreeing to a transfer means ceding up control on the license that you initially contributed under. Read another way: - the FSF says "this code is GPLv2" - someone contributes under that GPLv2 promise, cedes copyright to the FSF because it's "the process" - the FSF says "this code is now GPLv3 exclusively" - that someone says "but that was not the deal!" - the FSF says "I am altering the deal, pray I don't alter it any further."
jeffbee 1y ago
These allocators often have higher startup cost. They are designed for high performance in the steady state, but they can be worse in workloads that start a million short-lived processes in the unix style.
- kstrauser 1y ago
  Oh, interesting. If that's the case, I can see why that'd be a bummer for short-lived command line tools. "Makes ls run 10x slower" would not be well received. OTOH, FreeBSD uses it by default, and it's not known for being a sluggish OS.
favorited 1y ago
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 rest. Which is why you see it recommended so frequently with services, where there is generally one process that you want to get preferential treatment over everything else.
- jeffbee 1y ago
  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.
  - favorited 1y ago
    It's possible that they were referring to something specific about their platform and its system allocator, but like I said it was an anecdote about one engineer's statement. I just remember thinking it sounded fair at the time.
    - vlovich123 1y ago
      The “system” allocator is managing memory within a process boundary. The kernel is responsible for managing it across processes. Claiming that a user space allocator is greedily inefficient is voodoo reasoning that suggests the person making the claim has a poor grasp of architecture.
      - jdsully 1y ago
        The "greedy" part is likely not releasing pages back to the OS in a timely manner.
        1y ago
o11c 1y ago
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 these "multi-threading-first allocators" aren't actually buying anything of value, and they do have a lot of overhead. 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)
- vlovich123 1y ago
  That’s actually particular try to alternate allocators and not true for glibc if I recall correctly (it’s much worse at returning memory).
- senderista 1y ago
  > 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
  - LtdJorge 1y ago
    Why is that? Doesn't Linux use SIMD for the crypto operations?
    - dwattttt 1y ago
      Allowing SIMD instructions to be used arbitrarily in kernel actually has a fair penalty to it. I'm not sure what Linux does specifically, but: When a syscall is made, the kernel has to backup the user mode state of the thread, so it can restore it later. If any kernel code could use SIMD registers, you'll have to backup and restore that too, and those registers get big. You could easily be looking at adding a 1kb copy to every syscall, and most of the time it wouldn't be needed.
toast0 1y ago
It is on FreeBSD. :P Change your malloc, change your life? May as well change your libc while you're there and use FreeBSD libc too, and that'll be easier if you also adopt the FreeBSD kernel. I will say, the Facebook people were very excited to share jemalloc with us when they acquired my employer, but we were using FreeBSD so we already had it and thought it was normal. :)
b0a04gl 1y ago
[dead]

sanxiyn 1y ago

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.

kstrauser 1y ago
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.
- lloeki 1y ago
  > I could easily imagine it being left out of glibc because [...] ... its license is BSD-2-Clause ;) hence "political"
  - vkazanov 1y ago
    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.
    - lloeki 1y ago
      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 https://sourceware.org/glibc/wiki/CopyrightFSForDisclaim As I recall this is what prevented Apple from contributing C blocks† back to upstream GCC. † https://github.com/lloeki/cblocks-clobj https://github.com/lloeki/cblocks-clobj
      - vkazanov 1y ago
        What prevents apple from working with gpl-style licenses is strict hatred towards code that they can't use without opensourcing it. So this is what prevents them from contributing to gpl projects: the need to control access to code. Llvm is OK for them from this point of view: upstream is open but they can maintain and distribute their proprietary fork.
        lloeki 1y ago
        > What prevents apple from working with gpl-style licenses is strict hatred towards code that they can't use without opensourcing it. Specifically regarding the C blocks feature introduced in Snow Leopard, as I recall, Apple wrote implementations for both clang and gcc, attempted to upstream the gcc patchset, said gcc patchset was obviously under a GPL license, but the GCC team threw a fit because it wanted the code copyright to be attributed to the FSF, and that ended up as a stalemate. If there was any hatred they could literally have skipped the whole gcc implementation + patchset upstreaming attempt altogether. Also they did have patchsets of various sizes on other projects, whose code ends up obviously being GPL as well. The "hatred" came later with the GPLv3 family and the patent clause, which is a legal landmine, the FSF stating that signing apps is incompatible with the GPLv3, and getting hung up on copyright transfer. From https://lwn.net/Articles/405417/ https://lwn.net/Articles/405417/ > Apple's motives may not be pure, but it has published the code under the license required and it's the FSF's own copyright assignment policies that block the inclusion. The code is available and licensed appropriately for the version of GCC that Apple adopted. It might be nice if Apple took the further step of assigning copyright to the FSF, but the GPLv3 was not part of the bargain that Apple agreed to when it first started contributing to GCC. The intent behind such copyright transfer is generally so that the recipient of the transfer can relicense without having to ask all contributors. Essentially as a contributor agreeing to a transfer means ceding up control on the license that you initially contributed under. Read another way: - the FSF says "this code is GPLv2" - someone contributes under that GPLv2 promise, cedes copyright to the FSF because it's "the process" - the FSF says "this code is now GPLv3 exclusively" - that someone says "but that was not the deal!" - the FSF says "I am altering the deal, pray I don't alter it any further."

jeffbee 1y ago

These allocators often have higher startup cost. They are designed for high performance in the steady state, but they can be worse in workloads that start a million short-lived processes in the unix style.

kstrauser 1y ago
Oh, interesting. If that's the case, I can see why that'd be a bummer for short-lived command line tools. "Makes ls run 10x slower" would not be well received. OTOH, FreeBSD uses it by default, and it's not known for being a sluggish OS.

favorited 1y ago

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 rest. Which is why you see it recommended so frequently with services, where there is generally one process that you want to get preferential treatment over everything else.

jeffbee 1y ago
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.
- favorited 1y ago
  It's possible that they were referring to something specific about their platform and its system allocator, but like I said it was an anecdote about one engineer's statement. I just remember thinking it sounded fair at the time.
  - vlovich123 1y ago
    The “system” allocator is managing memory within a process boundary. The kernel is responsible for managing it across processes. Claiming that a user space allocator is greedily inefficient is voodoo reasoning that suggests the person making the claim has a poor grasp of architecture.
    - jdsully 1y ago
      The "greedy" part is likely not releasing pages back to the OS in a timely manner.
      - 1y ago

o11c 1y ago

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 these "multi-threading-first allocators" aren't actually buying anything of value, and they do have a lot of overhead. 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)

vlovich123 1y ago
That’s actually particular try to alternate allocators and not true for glibc if I recall correctly (it’s much worse at returning memory).
senderista 1y ago
> 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
- LtdJorge 1y ago
  Why is that? Doesn't Linux use SIMD for the crypto operations?
  - dwattttt 1y ago
    Allowing SIMD instructions to be used arbitrarily in kernel actually has a fair penalty to it. I'm not sure what Linux does specifically, but: When a syscall is made, the kernel has to backup the user mode state of the thread, so it can restore it later. If any kernel code could use SIMD registers, you'll have to backup and restore that too, and those registers get big. You could easily be looking at adding a 1kb copy to every syscall, and most of the time it wouldn't be needed.

toast0 1y ago

It is on FreeBSD. :P Change your malloc, change your life? May as well change your libc while you're there and use FreeBSD libc too, and that'll be easier if you also adopt the FreeBSD kernel. I will say, the Facebook people were very excited to share jemalloc with us when they acquired my employer, but we were using FreeBSD so we already had it and thought it was normal. :)

b0a04gl 1y ago

[dead]