Date: Thu, 9 Feb 2023 15:31:57 +0000 From: David Chisnall <theraven@FreeBSD.org> To: "Floyd, Paul" <paulf2718@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: CFT: snmalloc as libc malloc Message-ID: <2429423C-C66C-4466-AE47-AE72B67C41E9@FreeBSD.org> In-Reply-To: <3bacad17-ff6b-8bd3-0559-a70274dcd632@gmail.com> References: <2f3dcda0-5135-290a-2dff-683b2e9fe271@FreeBSD.org> <3bacad17-ff6b-8bd3-0559-a70274dcd632@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Feb 2023, at 13:12, Floyd, Paul <paulf2718@gmail.com> wrote: >=20 > Another allocator to add to my list. I'll give it a go some time, but = I have a lot of things on my plate at the moment. >=20 > I had a quick look. Do you support reallocf? Not in snmalloc itself. FreeBSD libc supports this as a wrapper around = realloc: = https://github.com/freebsd/freebsd-src/blob/6332ef8941999b0c074d1ece0e1e10= 8447c70b98/lib/libc/stdlib/reallocf.c#L34 So libc using snmalloc does support it. > Looking to the fairly short term future, I couldn't see anything for = the upcoming C23 sized/aligned free functions. It may be premature as = the standard isn't out yet. Most of those can be implemented using the same underlying APIs as = posix_memalign, we can add them once they=E2=80=99re standardised. The = libc++ implementations of the C++ equivalents all simply wrap = posix_memalign. > Recently I did some work on adding a warning for realloc of size 0 to = Valgrind (not finished code review yet). I see that you 'free and return = NULL' (in the same camp as glibc and ptmalloc). However, jemalloc is in = the other camp "maybe free and return a pointer to something" (along = with Solaris and musl). That's not really an issue since realloc of 0 is = "implementation defined". However, it is slated to become UB in C23. We used to return NULL on malloc(0), and subsequently also on = realloc(0). We changed it because sort and (I think) pkg both call = realloc via a wrapper that checks for a NULL return and calls abort, yet = also pass 0 as an argument to realloc. This meant that I was unable to = buildworld after this, which was quite exciting (especially since I = forgot to create a boot environment before that update) - most other = things worked, but some key bits of FreeBSD didn=E2=80=99t. Our malloc code path could be shortened slightly if we could rely on = code accepting behaviour that conforms to the standard from malloc, = rather than the behaviour that glibc=E2=80=99s malloc happens to = provide. I was quite surprised to see this from code in the FreeBSD = base system, since none of the third-party code that I=E2=80=99ve used = with snmalloc had this behaviour. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2429423C-C66C-4466-AE47-AE72B67C41E9>