Re: [Gc] Collecting large memory blocks
ivmai at mail.ru
Fri Dec 4 02:43:16 PST 2009
"Christian Gudrian" <christian at gudrian.org> wrote:
> Am 02.12.2009, 18:59 Uhr, schrieb Ivan Maidanski <ivmai at mail.ru>:
> > 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
> > 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: https://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2532
> 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?
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...)
- 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