[gclist] Two conservative collectors

[Charles Fiterman]

At 10:04 AM 11/18/99 -0800, Boehm, Hans wrote:
>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.

Our inhouse use of debug info is approaching the point where a precise scan
of the stack would make sense. 

As to traceback info, to be useful this involves understanding data
definitions. I'm sure you can give it in hex but what earthly good is that
to humans. Traceback has to say things like

  filex.cpp:17 frobNick *foo == 0x127080 (vtbl frobNick)
  0x127088 (char *)name == 0x141200 (no vtbl)

You would be saying

  0x560800 == 0x127080
  0x127088 == 0x141200