On 10 Jun 2025, at 00:17, Warner Losh <i...@bsdimp.com> wrote: > > I'm unsure what to do in the future. What are all the cool kids using today?
I’ve replaced jemalloc with snmalloc (to which I am a contributor) in libc about five years ago and have been using that on a few places. I believe Brooks imported a cleaned-up version of my patches to CheriBSD and was planning on upstreaming them as an option. - For building llvm, snmalloc was around 2% faster. I didn’t do much benchmarking because I was mostly on VMs but across SPEC on Linux (where we did more benchmarking) we were typically faster than jemalloc. - The libc binary is around 500 KiB smaller. - The HAL supports FreeBSD upstream (there’s also a HAL for running snmalloc in the kernel too, but it is bitrotted). It’s easy to tune things for performance or memory overhead. - It makes it easy to do fun things like allocate across trust boundaries. We use this in the verona-sandbox project to easily compartmentalise libraries with capsicum. We built snmalloc as a set of tools to build allocators, rather than as a malloc. The same code can be used to build specialised allocators. - It makes it easy to find the start and end of allocations. My version has checks on memcpy and an older prototype did bounds checks on things like sprintf and so on. These have around a 2% performance overhead with checks on writes. I have some ifunc magic to dynamically switch between the two versions for memcpy. Not that I’m biased or anything... David
