[Gc] Delayed collection of objects?

Boehm, Hans hans_boehm@hp.com
Fri, 27 Jun 2003 17:00:50 -0700

> From: David Jones [mailto:dej@inode.org]
> After upgrading to 6.2alpha6 and enabling the debug options, 
> I get the 
> following:
> % find_class_refs VerilogScope
> 0x816d6e0 0x816de60 
> % gc_backtrace 0x816d6e0
> 0x816d6e0 (/usr/local/include/gc_cpp.h:269, sz=28)
>         Caller at allocation:
>                 ##PC##= 0x8072cc0
> Reference could not be found
> VerilogScope is temporary information used by a parser.  Once 
> the file is 
> parsed, the scope is no longer needed and is (theoretically) 
> thrown away.
> If I force a collection at this point, the object at 
> 0x816d6e0 will STILL not 
> be reclaimed.
> However, if I continue to perform other commands, then the 
> object will 
> eventually be reclaimed.  I would prefer that objects be 
> reclaimed as soon as 
> possible, as a VerilogScope can transitively reference many 
> megabytes of 
> objects.
How did you determine whether the object was reclaimed?

The normal lifetime of a small object like this goes something like:

1. Object is allocated.

<Object is alive.  Potentially many GCs happen.>

2. Some collection notices that it is no longer reachable.  If you put
a breakpoint in GC_finish_collection, you will see that GC_is_marked(p)
is 0 at this point.  It will be 1 after prior collections.

3. If the object is finalizable, its mark bit will be set again, deferring
reclamation to the next GC cycle, but it will be queued for finalization.

4. The page on which the object resides is enqueued for sweeping.
(Or possibly the whole page is deallocated at this point.  In neither
case is it cleared or overwritten.)

5. The world is restarted.

6. When an object of the right size is needed, the relevant page is swept,
and the object is added back to the appropriate free list.  At this point
at least the first word is overwritten.

7. The object is reallocated from the free list.

It looks to me like you don't get a complete backtrace (i.e. one that ends in a
root) for either example.  This could happen if either the object actually
didn't get marked (which might also explain the disappearing object) or if
not everything were allocated through GC_debug_malloc and friends.