Proposed addition of malloc_size_np()
jasone at FreeBSD.org
Mon Mar 27 16:34:53 UTC 2006
John Baldwin wrote:
> On Sunday 26 March 2006 13:04, Jason Evans wrote:
>>Robert Watson wrote:
>>>I wonder if the intuitive objection people are raising is actually with
>>>the name. Since malloc_size() is defined on at least one platform to
>>>return the requested size, maybe a name like malloc_allocated_size() (or
>>>something a bit more compact) would help avoid that confusion, and make
>>>it clear that the consumer is getting back a commitment and not a hint
>>>for future realloc(), etc.
>>Maybe you're right. We could just call it malloc_usable_size() and be
>>compatible with Linux.
> It would help to know why such a function would be useful. :) Do you have
> a specific use-case? If the purpose is for a program to see that it really
> as Y >= X bytes when it did malloc(X) so that the program can use Y bytes,
> that would seem to only be a source of bugs and complexity. If the program
> wants Y bytes, it should malloc(Y). Many folks in the thread seem to think
> that this function would be used for a poor-man's realloc() wrapper or
> something, and I think such uses would be short-sighted at best. If there
> are other uses such as for having a debug malloc wrap the real one, then
> that might justify the API, but it is unclear what a useful use of this API
> would be.
I can think of a few straightforward uses:
1) Suppose that we are about to write to a string that we know is
malloc()ed, and we want to be sure that we aren't overflowing the
allocated buffer. We can add an assertion that the buffer is indeed
large enough to contain what is about to be written to it.
2) Suppose that we are using some sort of dynamically scalable data
structure, such as a hash table that we double in size every time
fullness crosses some threshold. In order to do that, we need to know
how large the table is. We can store that information, or we could just
query the size. (In this example, performance constraints might dictate
that we actually store the size of the table, but there are certainly
similar examples that wouldn't be so concerned with performance.)
3) This is what I want malloc_usable_size() for: garbage collection. In
order for a garbage collector to know when it should run, there needs to
be some way of tracking how much memory is in use. By using
dlsym(RTLD_NEXT, ...), I can intercept all malloc/calloc/realloc/free
calls and track current memory usage. However, unless there is a way of
getting the size of each allocation, I don't know how much to subtract
from the count for realloc/free calls.
4) Porting code from Linux. Case in point: Xara Xtreme, currently being
ported by Vasil Dimov. At the moment, he has to use dlmalloc.
Following is what I've written for the malloc(3) man page:
The malloc_usable_size() function returns the usable size of the
allocation pointed to by ptr. The return value may be larger than the
size that was requested during allocation. malloc_usable_size() is not
intended as a mechanism for in-place realloc(), though it can be abused
that way; rather it is primarily provided as a tool for introspection
purposes. Any discrepancy between the requested allocation size and the
size reported by malloc_usable_size() should not be depended on, since
such behavior is entirely implementation-dependent.
More information about the freebsd-arch