On Wed, Jun 11, 2025 at 06:53:29AM +0300, Konstantin Belousov wrote: > On Tue, Jun 10, 2025 at 10:54:34AM -0600, Warner Losh wrote: > > On Tue, Jun 10, 2025 at 6:53???AM Brooks Davis <bro...@freebsd.org> wrote: > > > > > > On Tue, Jun 10, 2025 at 08:15:02AM +0100, David Chisnall wrote: > > > > 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. > > > > > > > > > > I've been doing infrastructure work for this as a background task > > > due to a decision to switch back to a wrapped jemalloc for CheriBSD > > > heap temporal safety work (at the time we were debugging too many > > > different things at once and decided that wrapping jemalloc meant we > > > were debugging fewer things). > > > > > > I think we should ship 15.0 with jemalloc, ideally updated to at least > > > 5.3.0. I'd also like to deprecate all the jemalloc specific symbols for > > > 15 by removing default versions. I've got a patch to do so, but probably > > > need an exprun for it and maybe a shim library to allow linkage with > > > those symbols. > > > > I agree. I have staged this, but am working through a few of the last > > snags in completely scripting the upgrade so that it's maximally > > auditable after the xz compromise. While I don't think we have a big > > risk of that, I think some caution is needed. I like the idea of > > deprecating the specific symbols... but that's contingent on exprun > > since I think we do use them in a few ports (or used to, I reviewed > > something that did years ago). > > > > > Longer term, pivoting to a malloc with better hardening is certainly the > > > right thing to do and snmalloc is a candidate. > > > > Yea, we need something that's maintained and still innovating. While > > malloc is a relatively stable interface, getting good performance out > > of it for the changing dynamic of applications requires constant study > > and tuning... I don't know enough to know if snmalloc is the best > > choice for us or not, but I do think we should be intentional about > > this and if there's a number of people that can guide the process, so > > much the better. > > I believe before ever starting importing any such mallocs, we need to > get rid of the malloc uses in C runtime. I already did that for some > critical parts of libthr, perhaps whole libthr should be malloc-free. > > Then, libc uses of malloc needs to be audited, and stuff like TLS > allocations get rid of it. Perhaps it is fine and even necessary to > continue using malloc for e.g. asprintf(), gai, etc, which do not > participate in C runtime proper. > > This should make malloc integration much less demanding. Perhaps libc > could be converted to filter for malloc symbols, like it is for libsys.
Currently the only deeply integrated bits are the __je_bootstrap_* bits in TLS. I don't know of anything else should change. asprintf() absolutely must use malloc because its allocation must be passable to free. It might be there are some things with their own free interface that don't need to use the system malloc, but IMO there's little reason not to. We've got a patch in CheriBSD to use a separate malloc in TLS. It's essentially using a local copy of rtld_malloc as a tls_malloc, but structured differently due to CheriBSD history. Reconverging with FreeBSD is on our to do list. I've sometimes pondered extracting the malloc implementation from libc, but I'm a bit less convinced of the value than with libsys. I don't think it would be terribly hard to do. -- Brooks
