Re: [Gc] Changing ‘GC_should_collect’ to account for malloc’d memory

Bruce Hoult bruce at
Sat Feb 26 17:14:28 PST 2011

On Sun, Feb 27, 2011 at 3:47 AM, Ludovic Courtès <ludo at> wrote:
>  Firstly, port objects are more than meets the eye: the eye of the
>  garbage collector, that is. Besides the memory that they have that GC
>  knows about, they also in general have iconv_t pointers for doing
>  encoding conversions.  Those iconv_t values hide kilobytes of
>  allocation, on GNU anyway. [...]
>  See, the GC only runs when it thinks it's necessary. Its idea of
>  "necessary" depends, basically, on how much has been allocated since
>  it last ran. The iconv_t doesn't inform this decision, though; to the
>  GC, it is dark matter. So it is possible for the program to outrun the
>  GC for a while, increasing RSS in the part of the heap the GC doesn't
>  scan or account for.
> So, how can we make ‘GC_should_collect’ account for memory that’s
> malloc’d behind libgc’s back?
> A simple and lightweight solution would be to use Glibc’s malloc hooks,
> where available, so that malloc calls go through libgc, giving it a
> better idea of how much heap is in use (patch attached.)

I don't think the GC should consider all malloc'd memory, but only
memory which might be freed as a result of a collection.

It might make sense to have an API that allows objects that register a
finalizer to say how much non-GC memory will be freed when the
finalizer is run.

More information about the Gc mailing list