From owner-freebsd-arch@FreeBSD.ORG Sat Mar 25 08:23:08 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 E2A4816A41F for ; Sat, 25 Mar 2006 08:23:07 +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 8324243D48 for ; Sat, 25 Mar 2006 08:23:07 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id 4E7A45E4906; Sat, 25 Mar 2006 00:23:07 -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 17AC05E4906; Sat, 25 Mar 2006 00:23:06 -0800 (PST) Message-ID: <4424FDE9.3080707@FreeBSD.org> Date: Sat, 25 Mar 2006 00:23:05 -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: Matthew Dillon References: <44247DF1.8000002@FreeBSD.org> <200603250806.k2P86YJU011861@apollo.backplane.com> In-Reply-To: <200603250806.k2P86YJU011861@apollo.backplane.com> 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: 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: Sat, 25 Mar 2006 08:23:08 -0000 Matthew Dillon wrote: > : > :=== Proposal === > :Add malloc_size_np() to libc, and provide the prototype in malloc_np.h: > : > : size_t > : malloc_size_np(const void *ptr); > : > :This function would return the usable size of the allocation pointed to > :by ptr, which is always greater than or equal to the size that was > :specified in the call to malloc(), calloc(), posix_memalign(), or > :... > > That creates a serious race condition for any threaded program, > since multiple threads might be malloc()ing memory at the same > time and one could wind up using the 'extra' space that abuts > an allocation being tested by some other thread. It sounds like I wasn't clear enough about the motivation for the vague specification of malloc_size_np()'s return value. The issue I am concerned about is that an allocator implementation does not actually have to store the precise allocation request size; it can instead round the request size up internally, then treat the allocation as being of this rounded up size. By vaguely specifying the return value of malloc_size_np(), we grant the malloc implementation freedom as to whether the size is precisely what was specified during allocation, or some rounded up value. I had no intention of suggesting that malloc_size_np() should extend existing allocations, nor change the return value depending on the current state of memory following the allocation pointed to by ptr. > Maybe something like: > > n = realloc_try(ptr, bytes) > > This function attempts to extend the size of a previously allocated > memory block without changing its pointer. The total size of the > (now possibly extended) memory pointed to by pointer is returned. The > total size returned will always be at least min(bytes, previous_size) > and will never exceed (bytes). The function cannot fail, but may not > return the requested number of bytes. > > This function may also be used to truncate the size of a previously > allocated memory block without changing its pointer. This function > will always return (bytes) when the passed bytes is less then or > equal to the size of the current allocation. The function does NOT > guarentee that the memory allocator can actually use the freed memory > past the truncation point for other unrelated allocations, but it DOES > guarentee that, baring other allocations that reuse the memory, the > current allocation can be extended back into the truncated area with > another call to realloc_try(). > > -- > > That would give you the most flexibility and be relatively opaque to the > actual malloc implementation. The degenerate case would only have > to determine the size of the current allocation to return a meaningful > result (even if it doesn't actually extend or truncate it), and that > information clearly must already be attainable since the original > allocation size is not specified when you free() the memory. This actually does make some assumptions about the way memory is managed by malloc. It would not be useful in the context of phkmalloc or jemalloc to truncate an allocation via realloc_try(), because each page of memory contains allocations of only one size class. Thus, there is no way to re-use the trailing space (exception: multi-page allocations). This would potentially be useful for dlmalloc (or ptmalloc) though. Thanks, Jason