From owner-freebsd-arch@FreeBSD.ORG Mon Mar 27 16:34:53 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 0DFD516A400; Mon, 27 Mar 2006 16:34:53 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id B55AC43D64; Mon, 27 Mar 2006 16:34:44 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id 89D255E4906; Mon, 27 Mar 2006 08:34:44 -0800 (PST) Received: from [192.168.168.201] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id E673F5E48C1; Mon, 27 Mar 2006 08:34:42 -0800 (PST) Message-ID: <44281421.3060401@FreeBSD.org> Date: Mon, 27 Mar 2006 08:34:41 -0800 From: Jason Evans User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <44247DF1.8000002@FreeBSD.org> <20060326110929.V35431@fledge.watson.org> <4426D7A0.4040007@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> In-Reply-To: <200603271110.02917.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.5 (2005-11-28) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.5 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 16:34:53 -0000 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. 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. ----