Re: Proposed addition of malloc_size_np()



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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Proposed addition of malloc_size_np()
    ... ported by Vasil Dimov. ... variable AvailableRAM - the realloc() wrapper decreases AvailableRAM ...
    (freebsd-arch)
  • Re: sizeof([ALLOCATED MEMORY])
    ... No, you couldn't necessarily avoid the realloc altogether, unless the ... The allocator may give you extra memory for free but currently has ... Let's call it xrealloc(). ...
    (comp.lang.c)
  • Re: How to force fscanf to find only data on a single input line?
    ... allocator out there where it changes the number of reallocations, ... Avoiding wasting time copying memory on realloc. ... hiatuses when releasing large numbers of allocated blocks. ... free action reduces memory blockage due to ...
    (comp.lang.c)
  • Re: validate pointer that was returned from malloc
    ... Kristofer Pettijohn wrote: ... > You would have to write your own wrapper for malloc for that one - ... it's just a screwy allocator */ ...
    (comp.lang.c)
  • Re: sizeof([ALLOCATED MEMORY])
    ... I don't know any malloc implementation that does not store the size. ... If all known malloc implementations (check every ... the size of the allocated block is trivially easy to discover -- it's usually a few bytes before the address mallocor realloc() returns. ... allocator and you must do something similar to "strlen", ...
    (comp.lang.c)