Date: Tue, 10 Jun 2025 08:15:02 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Minsoo Choo <minsoochoo0122@proton.me>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: Future of jemalloc on FreeBSD after archive Message-ID: <44DDF236-0911-4CE8-AD30-5E1AB5CB25EB@FreeBSD.org> In-Reply-To: <CANCZdfpgLQD0sC3Hsuy542b1K%2BSpNA8xLGZ96XoOZhhLc1%2Buhg@mail.gmail.com> References: <sLUPmdWvgjaNJL3ly0NC29emSncHWcPnwkuqJ_v_T2_OsBK9BtdJcm17AeGD-2VBZp7gLEpMis-PiJG7zOueEcBhfVIlIpSVNKWfEgmKFn4=@proton.me> <CANCZdfpgLQD0sC3Hsuy542b1K%2BSpNA8xLGZ96XoOZhhLc1%2Buhg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 10 Jun 2025, at 00:17, Warner Losh <imp@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 [-- Attachment #2 --] <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On 10 Jun 2025, at 00:17, Warner Losh <imp@bsdimp.com> wrote:<br><div><blockquote type="cite"><br class="Apple-interchange-newline"><div><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">I'm unsure what to do in the future. What are all the cool kids using today?</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"></div></blockquote></div><br><div>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.</div><div><br></div><div> - 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.</div><div> - The libc binary is around 500 KiB smaller.</div><div> - 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.</div><div> - 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.</div><div> - 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.</div><div><br></div><div>Not that I’m biased or anything...</div><div><br></div><div>David</div><div><br></div></body></html>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44DDF236-0911-4CE8-AD30-5E1AB5CB25EB>