From owner-freebsd-arch@FreeBSD.ORG Mon Mar 27 17:49:05 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC52816A401; Mon, 27 Mar 2006 17:49:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74F3943D46; Mon, 27 Mar 2006 17:49:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.37]) by a50.ironport.com with ESMTP; 27 Mar 2006 09:49:06 -0800 Message-ID: <44282590.9070304@elischer.org> Date: Mon, 27 Mar 2006 09:49:04 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: <44247DF1.8000002@FreeBSD.org> <20060326110929.V35431@fledge.watson.org> <4426D7A0.4040007@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> <44281421.3060401@FreeBSD.org> In-Reply-To: <44281421.3060401@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vasil Dimov , Robert Watson , freebsd-arch@freebsd.org Subject: Re: Proposed addition of malloc_size_np() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 17:49:05 -0000 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"