[Gc] Delayed collection of objects?

David Jones dej@inode.org
Tue, 24 Jun 2003 10:21:09 -0400

Does the collector delay reclaiming memory for any reason?

I have an application that is consuming more memory than I'd like it to.  I 
have added instrumentation code to it that demonstrates that objects that I 
have no further use for are surviving GC.

The application is Tcl-based, so I can give interactive commands to drive my 

After upgrading to 6.2alpha6 and enabling the debug options, I get the 

% 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 

On a similar note:

% find_class_refs DBLibrary 
0x816ed90 0x816ee80 
% gc_backtrace 0x816ed90
0x816ed90 (/usr/local/include/gc_cpp.h:269, sz=36)
        Caller at allocation:
                ##PC##= 0x80df616

Reachable via 0 levels of pointers from offset 12 in object:
0x816df20 (/usr/local/include/gc_cpp.h:269, sz=28)

% gc_backtrace 0x816ee80
0x816ee80 (/usr/local/include/gc_cpp.h:269, sz=36)
        Caller at allocation:
                ##PC##= 0x80b9252

Reachable via 0 levels of pointers from offset 16 in object:
0x816df20 (/usr/local/include/gc_cpp.h:269, sz=28)

Now, in GDB:

(gdb) p {struct XactReference}0x816df20
$2 = {<xeda_gc> = {<xeda_gc_cookie> = {
      crumbs = 791480447}, <gc> = {<No data fields>}, 
    _vptr$xeda_gc = 0x81277e0, more_crumbs = -791480448}, current = 0x816ed90, 
  saved = 0x0, xact = 0x0, link = 0x0}
(gdb) x/10lx 0x816df20
0x816df20:      0x081277e0      0x2f2d087f      0xd0d2f780      0x0816ed90
0x816df30:      0x00000000      0x00000000      0x00000000      0xb4c812cf
0x816df40:      0xf7e9107b      0x00000000

Sorry, but 0x816ee80 just ain't there any more!  Yet, it will not be 
reclaimed. (The object 0x816ed90 is legitimate, and is the only DBLibrary 
object that I expect to be in existence.)

Any ideas on how I should proceed from this point?