[gclist] conservative vs. "precise" gc

[Hans Boehm]

It may be worth emphasizing again that there are different possible
degrees of conservativism with different tradeoffs.  The major possibilities
are something like:

1. Only scan the top activation record conservatively.  Generate stack layout
descriptors for call sites.  This makes lots of sense to me even if you
complete control over the compiler.  The main benefit
is that it allow you to run with a conventional thread system
(or UNIX signals) without adding
safe points.  It can also easily be extended to give you better C
intercallability.  There is some minimal risk of accidental retention.  But
there are very few systems that don't already include much larger risks
of this form.

2. Conservatively scan stack(s).  Might still make sense with a custom
compiler, since you don't have to generate descriptors for procedure frames.
(It has been used by several such compilers, e.g. D-machine Cedar and
SRC Modula 2+.)  Empirically most of the leakage risk here comes from
dead stack pointers that haven't been overwritten.  This risk is more
significant on RISC machines than Intel architecture machines.  The problem
seems to show up nearly exclusively in toy benchmarks with very deep stacks,
and that can largely be handled with some slightly tricky allocator code.
This usually makes sense if you're programming in C or generating C code.

3. Also conservatively scan parts or all of the heap and/or static data
areas.  This makes sense to me if you are dealing with hand-written C/C++ code
or C intercallability is a big issue.  With a well-tuned collector, the
leakage risk is still minor.  But there will be occasional situations in
which you do have to specify some information about pointerfree areas etc.,
to keep space performance reasonable.  Scanning large static data areas
is usually a performance loss, since pointer density tends to be 
extremely low.

Hans-J. Boehm
Standard disclaimer ...