5 ms·

For those curious, Musl's malloc implementation is currently being re-written for higher performance and robustness, see https://github.com/richfelker/mallocng-

For those curious, Musl's malloc implementation is currently being re-written for higher performance and robustness, see https://github.com/richfelker/mallocng-draft https://github.com/richfelker/mallocng-draft

liuliu 6y ago
Do you have any extra readings on the rationale of building their own malloc rather than integrating mimalloc or jemalloc?
- The_rationalist 6y ago
  The NIH syndrome obviously, otherwise it would have been addressed at the start of the Readme
- harrygeez 6y ago
  well one of the stated goals of musl is to be simple and correct, and all those mallocs are anything but simple
  - littlestymaar 6y ago
    That's true for jemalloc, but mimalloc is pretty simple. The reference paper is pretty short and really accessible and IIRC the implementation is around 5klocs. I doubt musl's implementation would much simpler than this.
    - dalias 6y ago
      5kloc is about 10x larger than musl's existing (old) malloc in source lines. I suspect lots of that is low code density, comments, etc. I have to lookup what exactly mimalloc is/does every time someone mentions it, because the readme/documentation isn't very descriptive except discussing extensions outside the normal API. I didn't have time to dig through this again today. But I did look at it in some depth on several occasions in the past and it really wasn't suitable for or comparable to what we're doing in musl.
      - littlestymaar 6y ago
        Thanks for clarification, didn't imagine that musl's malloc was that minimalist. You should definitely have a look at the paper [1] it's only ten page long! (Excluding benchmarks and references) [1]: https://www.microsoft.com/en-us/research/uploads/prod/2019/06/mimalloc-tr-v1.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
- jessermeyer 6y ago
  Not any first hand, but reading their principles suggests that simplicity and ease of deployment are probably relevant. https://musl.libc.org/about.html https://musl.libc.org/about.html
  - liuliu 6y ago
    Thanks. Taking on malloc and being competitive with much less code (mimalloc is around 6k, and it is the smallest I know that is still competitive) would be a great feat. Would be interesting to follow the development.
- AndyKelley 6y ago
  This is a libc implementation. The null hypothesis is that it implements libc, rather than porting a different libc implementation.
scott_s 6y ago
Curiously, it doesn't adopt the now-standard approach for multithreaded support: per-thread memory pools, allowing one thread allocating and deallocating the same memory to avoid synchronization. This uses one lock guarding allocation, which means that it can be a bottleneck in a multithreaded workload.
- dalias 6y ago
  The justifications are partly the same as what Daniel Micay has written extensively on in the rational for hardened_malloc (https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc) - unsynchronized per-thread state inherently sacrifices global consistency for performance and makes it impossible to detect a lot of types of memory usage errors (DF/UAF, etc) that could otherwise be caught. However musl has the additional constraint of being compatible with small/very-low-memory environments. Lack of global consistency inherently means you will end up using memory less efficiently and requesting significantly more from the system. The new malloc about to go upstream in musl is, to my knowledge, the first/only advanced hardened allocator using slab-type design rather than traditional dlmalloc type split/merge, but also designed for extremely low overhead/waste at low to moderate usage rather than extreme performance. And in the vast majority of applications, this is perfectly reasonable. Even Firefox for example does very well with it. With that said, new malloc is expected to be somewhat faster than old on lots of workloads (and considerably faster than old would be if we fixed the flaws in old that motivated it), but it's not a performance-oriented allocator. If you really want/need that you should probably link jemalloc or similar (and accept all the tradeoffs that come with that). In Rust programs without "unsafe", it may make sense to do that by default.
  - fluffything 6y ago
    > However musl has the additional constraint of being compatible with small/very-low-memory environments. How many threads do these have ? If they only have one thread, they'll use 72x less memory than if they would have 72 threads. The thing is that if you are using 72 threads you probably would like your application to be 72x faster than if you are using only one. So synchronizing all allocations and killing scalability doesn't solve these users problems. Most allocators, including jemalloc, tcmalloc, mimalloc, etc. have a "hardened" mode, that people can opt into if they want. If I'm using Rust like the user in the blog post, double frees are caught at compile-time, so I'd rather not pay for them at run-time.

liuliu 6y ago

Do you have any extra readings on the rationale of building their own malloc rather than integrating mimalloc or jemalloc?

The_rationalist 6y ago
The NIH syndrome obviously, otherwise it would have been addressed at the start of the Readme
harrygeez 6y ago
well one of the stated goals of musl is to be simple and correct, and all those mallocs are anything but simple
- littlestymaar 6y ago
  That's true for jemalloc, but mimalloc is pretty simple. The reference paper is pretty short and really accessible and IIRC the implementation is around 5klocs. I doubt musl's implementation would much simpler than this.
  - dalias 6y ago
    5kloc is about 10x larger than musl's existing (old) malloc in source lines. I suspect lots of that is low code density, comments, etc. I have to lookup what exactly mimalloc is/does every time someone mentions it, because the readme/documentation isn't very descriptive except discussing extensions outside the normal API. I didn't have time to dig through this again today. But I did look at it in some depth on several occasions in the past and it really wasn't suitable for or comparable to what we're doing in musl.
    - littlestymaar 6y ago
      Thanks for clarification, didn't imagine that musl's malloc was that minimalist. You should definitely have a look at the paper [1] it's only ten page long! (Excluding benchmarks and references) [1]: https://www.microsoft.com/en-us/research/uploads/prod/2019/06/mimalloc-tr-v1.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
jessermeyer 6y ago
Not any first hand, but reading their principles suggests that simplicity and ease of deployment are probably relevant. https://musl.libc.org/about.html https://musl.libc.org/about.html
- liuliu 6y ago
  Thanks. Taking on malloc and being competitive with much less code (mimalloc is around 6k, and it is the smallest I know that is still competitive) would be a great feat. Would be interesting to follow the development.
AndyKelley 6y ago
This is a libc implementation. The null hypothesis is that it implements libc, rather than porting a different libc implementation.

scott_s 6y ago

Curiously, it doesn't adopt the now-standard approach for multithreaded support: per-thread memory pools, allowing one thread allocating and deallocating the same memory to avoid synchronization. This uses one lock guarding allocation, which means that it can be a bottleneck in a multithreaded workload.

dalias 6y ago
The justifications are partly the same as what Daniel Micay has written extensively on in the rational for hardened_malloc (https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc) - unsynchronized per-thread state inherently sacrifices global consistency for performance and makes it impossible to detect a lot of types of memory usage errors (DF/UAF, etc) that could otherwise be caught. However musl has the additional constraint of being compatible with small/very-low-memory environments. Lack of global consistency inherently means you will end up using memory less efficiently and requesting significantly more from the system. The new malloc about to go upstream in musl is, to my knowledge, the first/only advanced hardened allocator using slab-type design rather than traditional dlmalloc type split/merge, but also designed for extremely low overhead/waste at low to moderate usage rather than extreme performance. And in the vast majority of applications, this is perfectly reasonable. Even Firefox for example does very well with it. With that said, new malloc is expected to be somewhat faster than old on lots of workloads (and considerably faster than old would be if we fixed the flaws in old that motivated it), but it's not a performance-oriented allocator. If you really want/need that you should probably link jemalloc or similar (and accept all the tradeoffs that come with that). In Rust programs without "unsafe", it may make sense to do that by default.
- fluffything 6y ago
  > However musl has the additional constraint of being compatible with small/very-low-memory environments. How many threads do these have ? If they only have one thread, they'll use 72x less memory than if they would have 72 threads. The thing is that if you are using 72 threads you probably would like your application to be 72x faster than if you are using only one. So synchronizing all allocations and killing scalability doesn't solve these users problems. Most allocators, including jemalloc, tcmalloc, mimalloc, etc. have a "hardened" mode, that people can opt into if they want. If I'm using Rust like the user in the blog post, double frees are caught at compile-time, so I'd rather not pay for them at run-time.