Date: Mon, 27 Mar 2006 09:49:04 -0800 From: Julian Elischer <julian@elischer.org> To: Jason Evans <jasone@freebsd.org> Cc: Vasil Dimov <vd@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Proposed addition of malloc_size_np() Message-ID: <44282590.9070304@elischer.org> In-Reply-To: <44281421.3060401@FreeBSD.org> References: <44247DF1.8000002@FreeBSD.org> <20060326110929.V35431@fledge.watson.org> <4426D7A0.4040007@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> <44281421.3060401@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans wrote: > 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. Iff it retunrs a numbre greater than teh alocated size, then this is a programmer error.. he should have malloc'd a bigger buffer. On the other hand malloc_allocated_size (which returns the allocated size) might be usefull if a library which is given a buffer wants to know how much room there is in a buffer. Of course there is nothing saying that we gave the library a pointer to the BEGINNING of the buffer so it should report "distance from the pointer to the end". Doesn't work for strings off the stack (alloca()) or static, etc > > 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.) As you say.. just store it... though a library wouldn't have access to that. > > 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. > > Jason > > 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. > ---- > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44282590.9070304>