From: Don Hamilton
Subject: uncollectable objects
Date: 
Message-ID: <26314@crdgw1.crd.ge.com>
Does anyone know of any tools, or approaches to detecting why
objects are not collectable by the garbage collector? 

______________________________________
Don Hamilton       ········@crd.ge.com
From: Rob MacLachlan
Subject: Re: uncollectable objects
Date: 
Message-ID: <1992Jan10.182704.202631@cs.cmu.edu>
In article <·····@crdgw1.crd.ge.com> ········@caesar.crd.ge.com (Don Hamilton) writes:
>Does anyone know of any tools, or approaches to detecting why
>objects are not collectable by the garbage collector? 

This is an important area which has not been much discussed.  I mentioned my
concern with "reference explanation" at the 91 OOPSLA GC workshop.  Someone
from Texas Instruments said that they had developed a tool for this purpose
which created inverse data structures describing the reference path to an
object.  You can think of this as a copy of the data structure with all
pointer arcs reversed.  In this representation, a breadth-first walk can be
used to find the shortest path from an arbitrary object to a root.

Of course a CONS (for example) doesn't have enough slots to represent the
unbounded number of pointers to it, so you have to use a move general
structure type to represent a node in the inverted data structure.

This reference explanation technique can't be implemented portably (nor, I
doubt can any conceivable technique).  The TI implementation described used
repeated scans of the heap to locate the pointers to the object, the pointers
to those objects, etc., presumably terminating when a root was reached.

Recently William Lott implemented a reference explanation tool for CMU Common
Lisp under Mach.  It uses a different technique which is more efficient when
the access path is long.  It inverts the entire heap at once (in a process
similar to copying garbage collection) and then searches that inverted
representation.

  Rob