Proposed addition of malloc_size_np()

[Andrew Reilly]

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