From owner-freebsd-arch@FreeBSD.ORG Tue Mar 28 10:19:55 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 85ED516A400 for ; Tue, 28 Mar 2006 10:19:55 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta03sl.mx.bigpond.com (omta03sl.mx.bigpond.com [144.140.92.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF2CD43D45 for ; Tue, 28 Mar 2006 10:19:54 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.4.160]) by omta03sl.mx.bigpond.com with ESMTP id <20060328101953.KYZN1358.omta03sl.mx.bigpond.com@areilly.bpc-users.org> for ; Tue, 28 Mar 2006 10:19:53 +0000 Received: (qmail 88617 invoked by uid 501); 28 Mar 2006 10:20:59 -0000 Date: Tue, 28 Mar 2006 21:20:59 +1100 From: Andrew Reilly To: Jason Evans Message-ID: <20060328102059.GB87799@gurney.reilly.home> References: <44247DF1.8000002@FreeBSD.org> <20060326110929.V35431@fledge.watson.org> <4426D7A0.4040007@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> <44281421.3060401@FreeBSD.org> <20060327185017.GF7001@funkthat.com> <352D1430-CC72-47EE-9E50-B1C4404ACA95@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <352D1430-CC72-47EE-9E50-B1C4404ACA95@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: John-Mark Gurney , Robert Watson , Poul-Henning Kamp , John Baldwin , 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: Tue, 28 Mar 2006 10:19:55 -0000 On Mon, Mar 27, 2006 at 12:52:17PM -0800, Jason Evans wrote: > [1] In a slightly more ideal world, we would add malloc_size() > instead of malloc_usable_size(), which would return the size that was > passed to malloc()/calloc()/realloc(). However, that would impose > implementation constraints on the allocator that would have far- > reaching implications. You could do this in your malloc wrapper, if you wanted: just have it maintain a (growable) hash table of sizes, keyed by allocation address. You'd return the real (asked-for) size as the malloc_useable_size(), but any client code of that function would have to behave sensibly in any case: it can't know that it isn't running against something like a traditional first-fit allocator or the like that doesn't round up. > I don't want to get into the details here, > but suffice it to say that requiring support for malloc_size() would > require a lot of extra space overhead for many allocator designs, > including for phkmalloc and jemalloc. I've just written my own allocator for an embedded project (extra constraints are often better served by changing API, imo.) Anyway, it's very simple, and malloc_useable_size would be quite slow; malloc_size would be impossible without something extra, like the hash-table that I mentioned. Incidentally, what should malloc_useable_size() do if passed a pointer that wasn't [cmr]alloc()'d? The same sort of warning/trap as free()? -- Andrew