Re: [RFC] Supporting malloc_usable_size

[DJ Delorie <dj@redhat.com>]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
> At that time, I thought this use was to avoid reallocating[1] when

You can't do an optimal realloc if you don't know what the usable size
is, but once you know the optimal size, calling realloc() should be a
valid way of telling the compiler what you're doing.  We just need to
ensure that our realloc() does the sane thing in such cases and I see no
problem with users doing it.

> that maybe providing a fast path for cases where the new
> size was within the current chunk size was the solution to the problem
> systemd was trying to solve with malloc_usable_size.

I think a fast path check would be good for performance anyway, but
let's not call it a solution, because it won't change the functionality,
just the speed.

> it is used as a way to query sizes of objects and hence eliminating
> the need to pass their corresponding sizes.

Since malloc_usable_size is nonstandard and intended for debugging, this
is a bad programming practice (as noted in the man page).  As such, I
see no need to spend effort on it, either to block it or to optimize it.
Caveat programmer.  As long as the function returns the correct value, I
have no desire to worry about it further ;-)

> I have an idea to support this abuse and at the same time, satisfy the
> compiler by giving it a hint of the new size.

That's a lot of work to avoid a call to realloc().  And if they're
calling into libc to get a record size, they already don't care about
optimal performance.

> The larger consequence of this patch though is that we further support
> the usage of malloc_usable_size for cases beyond diagnostics.  Do we
> want to do that?

To what extend do we support it *at all*, other than "it returns the
right number at the time it was called" ?

> If we do, should we also then make clear what kind of usage we support
> as a library, say, in the manual?

Our man page already says "The main use of this function is for
debugging and introspection".  The BSD manual says "The
malloc_usable_size() function is not a mechanism for in-place realloc();
rather it is provided solely as a tool for introspection purposes."

So clarifying the manual to be more in line with BSD is probably OK but
anything further than that is IMHO an API change.

We may want to add a caveat that the returned value is only valid until
the next call to any malloc family function, though, although I don't
see any way our code could make the usable size of an allocated chunk
*smaller*.  I don't think we've ever guaranteed that the heap metadata
is constant.

Maybe as a lark we could make 1% of the calls return an obviously wrong
value?  ;-)