Date: Tue, 28 Mar 2006 21:32:51 +1100 From: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> To: Vasil Dimov <vd@FreeBSD.org> Cc: Robert Watson <rwatson@freebsd.org>, Jason Evans <jasone@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Proposed addition of malloc_size_np() Message-ID: <20060328103251.GC87799@gurney.reilly.home> In-Reply-To: <20060328060714.GB97222@qlovarnika.bg.datamax> References: <44247DF1.8000002@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> <44281421.3060401@FreeBSD.org> <200603271520.11381.jhb@freebsd.org> <20060328060714.GB97222@qlovarnika.bg.datamax>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 28, 2006 at 09:07:14AM +0300, Vasil Dimov wrote: > On Mon, Mar 27, 2006 at 03:20:08PM -0500, John Baldwin wrote: > > On Monday 27 March 2006 11:34, Jason Evans wrote: > [...] > > > 4) Porting code from Linux. Case in point: Xara Xtreme, currently being > > > ported by Vasil Dimov. At the moment, he has to use dlmalloc. > > > > Does it contain a G/C of its own or some such? > > > > Here is what malloc_usable_size() is used for in Xara Xtreme: > * They keep track of how much (heap) memory is available. Maybe they > support an option like "do not use more that N MiB". This is achieved > by a wrappers to realloc() and free() which manipulate a global? > variable AvailableRAM - the realloc() wrapper decreases AvailableRAM > with (newsize - oldsize) where oldsize is retrieved with > malloc_usable_size(). The free() wrapper increases AvailableRAM with > what is returned by malloc_usable_size(). oh, yuck! How do they deal with malloc_usable_size() returning different answers for different calls, depending on the intervening history of allocator activity? What if malloc_usable_size() is not the same as the amount of memory that would be freed on free()? (This would certainly be the case if a traditional first-fit or best-fit algorithm was sitting underneath.) Or is it the definition supposed to encompas that situation (so that malloc_usable_size is the same as the argument to malloc(), even if there happens to be free memory after the allocation, that a realloc would use without copy? What if, instead, it was linked against a garbage colector, where free() might not actually do anything at all? > * Debugging purposes like keeping track of how much memory they > allocated, the filename and linenumber of the allocation > * They use a function similar to realloc(), but which receives the > number of bytes they need to increment the buffer with, rather than > the new size, so they call realloc(p,increment+malloc_usable_size(p)) > * A lot of other miscellaneous purposes where they should really keep > track of how many bytes they requested from malloc() rather than > calling malloc_usable_size(). It certainly sounds as though the correct way to deal with this application is to link it against it's preferred allocator, rather than the system one. It's obvious that it relies on a great deal of specific allocator behaviour. -- Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060328103251.GC87799>