[gclist] Two conservative collectors

[Boehm, Hans]

Adding to Charles' reply:

Our collector has a number of (mostly poorly documented) hooks to support
specification of type information, if you really want to do so.  There are
probably barely enough hooks that you can use it with full type information
if you choose.  But these aren't intended or needed for casual use with C
and C++.  (They are there for experimentation, and to support compilers for
other languages (e.g. Scheme or Java) that also happen to use the collector
and can automatically and robustly provide the information.  I believe there
are no current clients that try to scan the stack precisely, and doing so
would require a lot of work.)  For C or C++ code, I don't recommend much of
this, and I've never seen a case where anything like it is needed.
Identifying bitmaps and the like as pointer-free is generally sufficient.

The "bleeding edge" versions of our collector have a facility that will
answer questions about why object are being retained.  You can compile the
collector so it stores back pointers in all objects, and then ask about
those, either for individual objects, or for random samples.  The interface
for looking at this information in the standard collector is poor, but other
people (e.g. Manuel Serrano for Bigloo Scheme) are building better clients
for it.

My impression is that Geodesic is not really behind in this area.  But as an
open source project, I'm more comfortable releasing stuff that's half done
(hopefully with suitable disclaimers).  And the open source collector gets
used more with languages other than C/C++.

Hans 

-----Original Message-----
From: Larry Evans [mailto:cppljevans@earthlink.net]
Sent: Thursday, November 18, 1999 8:32 AM
To: gclist@iecc.com
Subject: Re: [gclist] Two conservative collectors


Since both the Boehm and Geodesic collectors are conservative, there
is the possibility, however remote, that "false pointers" will cause
garbage to be retained. (I'm basing this conclusion on section titled
"Problems of conservative garbage collection" on p. 235 [JL96].)

How can a programmer detect whether this is happening in his program
and how easy is it to correct?  Also, if a programmer can precisely
identify the "internal" pointers, (as done in [DE92] with the "RC
Maps"), once at the beginning of the program (i.e. before the 1st
statement of main), then how could each of these collectors take
advantage of that information?

[DE92]
  David L. Detlefs.
  "Garbage collection and runtime typing as a C++ library"
  in _USENIX C++ Conference_, Portland, Oregon, Auguest 1992
  USENIX Association

[JL96] 
  Richard Jones & Rafael Lins
  _Garbage Collection_
  Wiley, 1996