Re: [Gc] Changing ‘GC_should_collect’ to account for malloc’d memory
bruce at hoult.org
Sat Feb 26 17:14:28 PST 2011
On Sun, Feb 27, 2011 at 3:47 AM, Ludovic Courtès <ludo at gnu.org> 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