[gclist] What to say about GC (and free GC support SW for C/C++)

[Jeremy Fitzhardinge]

Paul R. Wilson wrote:
> This might be useful in conjunction with Hans's simple GC-safe compilation,
> to reduce the conservatism of conservative GC.  (If only for people who
> are overly worried about it---I'm *not* one of the people who's paranoid
> about conservative GC techniques myself.)

I'm currently using Boehm's GC to implement a Java runtime.  Its typed
object allocation allows us to do mostly-accurate tracing for language
objects while allowing us to use conservative GC for the C binding.  For
the most part however, we don't notice much in the way of improvement
from using typed allocation, since most objects are very pointer-dense,
and the non-pointers rarely look like pointers (I suspect we can
construct examples that go either way, of course).  It also seems like
too much work to generate code for precise scanning, and its easier and
faster to just regard all stack and registers as conservative roots. 
This is generally our most obvious source of false pointers: values left
over in register which are dead, but the GC can't tell.  That, and FP
values on the stack, often cause blacklisted areas.

We've certainly found that reusing Hans's code rather than writing our
own GC was a much better use of resources and resulted in reliable code
more quickly.  It also seems the lest portable part of the system is the
threads/GC interface, but Boehm's GC has already been ported to most of
the interesting targets.  We are using most of the GC's features to get
the best possible performance, and we've turned up bugs in the more
obscure parts of the GC library - but Hans fixed them, and the fixes are
folded into the base source.

> [Using a gdb-based tool to generate type-descriptors for C objects ]

I also like the idea of the allocator generating an infered type
descriptor - each object type has a tag, and the GC scanner compares
instances of objects with the same tag.  If it finds obvious
non-pointers at an offset in one object, it decides that it must be a
non-pointer in all such objects, and therefore incrementally builds a
type descriptor.  There's a paper on this technique (Boehm and someone),
but I haven't seen the implementation.  I'm curious to see if it
improves the allocation and scanning of our C structures, for which we
don't bother with type information (too error-prone to generate
manually, though the gdb-based tool seems like an interesting idea).  Of
course, it fails if you use unions or unsafe pointer practices, but we
don't.

	J