Date: Tue, 28 Mar 2006 21:20:59 +1100 From: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> To: Jason Evans <jasone@FreeBSD.org> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Robert Watson <rwatson@FreeBSD.org>, Poul-Henning Kamp <phk@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: Proposed addition of malloc_size_np() Message-ID: <20060328102059.GB87799@gurney.reilly.home> In-Reply-To: <352D1430-CC72-47EE-9E50-B1C4404ACA95@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> <20060327185017.GF7001@funkthat.com> <352D1430-CC72-47EE-9E50-B1C4404ACA95@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060328102059.GB87799>