Re: CFT: snmalloc as libc malloc

On 9 Feb 2023, at 13:12, Floyd, Paul <paulf2718@gmail.com> wrote:
> 
> 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.
> 
> 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/6332ef8941999b0c074d1ece0e1e108447c70b98/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’re 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’t.

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’s 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’ve used with snmalloc had this behaviour.

David