Re[4]: [Gc] Collecting large memory blocks

Ivan Maidanski ivmai at
Fri Dec 4 02:43:16 PST 2009

"Christian Gudrian" <christian at> wrote:
> Am 02.12.2009, 18:59 Uhr, schrieb Ivan Maidanski <ivmai at>:
> > This is the key phrase, I think - the data roots (that are scanned by
> > GC) contain values that look like pointers the allocated blocks, so the
> > collector can't recycle them.
> And these roots might be different depending on the application type.
> > Tip: if you have no global pointer variables, you can use the following
> > (to prevent GC from scanning static data roots at all):
> Unfortunately I have.  Some singleton classes need to store their data
> somewhere...
> > If you have a "limited set" of global pointer variables then you can try
> > to inform the collector about them after GC_clear_roots like:
> Sounds good.  I'll have a try.
> I'd rather build the collector without ALL_INTERIOR_POINTERS defined, but
> thanks to multiple inheritance I need to, though that involves a lot more
> work than required.  For example:
> Given a class C which inherits from A and B each of which have virtual
> methods. After
> C * c = new C;
> c points to the VMT of C which also happens to be the start of the memory
> allocated by new.  After
> B * b = c;
> b now points to the VMT of B, which generally differs from c.  The same is
> true for pointers to A.
> In this example there are only three valid pointers to the memory
> allocated by new.  To have the collector treat these three references
> correctly I need to have it treat _all_ possible references as valid (by
> defining ALL_INTERIOR_POINTERS).  I suppose this causes much overhead,
> doesn't it?

With large objects (practically).
Note also, this influences blacklisting. See also this:

> If it was possible to determine the pointers to the VMTs of a class and
> have the collector check references only against these set of pointers,
> wouldn't that improve performance?
> Christian

Yes, the multiple inheritance is somewhat problematic w/o ALL_INTERIOR_POINTERS (I have no C++ experience with GC, but Hans and others on the ML should know the things better...)

More tips:
- don't forget to insert GC_INIT() at the beginning of an app;
- portable clients shouldn't rely on whether GC is built with ALL_INTERIOR_POINTERS or JAVA_FINALIZATION (it's better to call GC_set_all_interior_pointers and GC_set_java_finalization at start-up (before GC_INIT()).


More information about the Gc mailing list