[gclist] Re: PPC & GC, or GC and threads

Hans Boehm boehm@hoh.mti.sgi.com
Tue, 27 Jan 1998 09:13:31 -0800

On Jan 27, 12:41pm, Dave Lloyd wrote:
> Indeed. Our Algol 68 and Fortran 90 compilers were designed with an
> integrated precise garbage collector (of the mark and sweep variety).
> The compiler tracks all references statically and ensures that
> *somewhere* there is a root pointer for all objects being manipulated.
> This root pointer may well be in an outer procedure frame - our calling
> convention includes the rule that references passed to procedures must
> be recorded in the ref map. In almost all cases, the worst this means is
> that there is a marginally redundant copy on the stack, but scope and a
> few compiler optimisations usually mean that this is not within a
> critical loop, but at the top of the frame. Since our GC is
> precise we don't care if the code-generator generates mangled pointers
> to improper parts of objects as long as the objects are rooted
> somewhere (and this can be several indirections away by leaning on the
> type system) .
Just to avoid confusion:  All of the above also applies to a conservative
mark-sweep collector, and with mild restrictions to a Bartlett-style mostly
copying collector.  It doesn't apply to a precise copying or otherwise
compacting collector.

> The main impact on the code-generator is when new objects
> are created, we have to take a little care in the 'gap' between
> allocation and initialisation - this is particularly important for
> compound objects which need several separate allocations, sometimes
> there has to be a temporary place holder (with a simplified type) in the
> refmap for the duration.
This clearly isn't an issue for our conservative collector.  But the difference
is actually due in part to the fact that we clear possibly-pointer-containing
objects in the allocator and you're probably not willing to do that.  Thus the
overhead (and then some) is moved to the allocator.  (If I knew the client was
going to promptly initialize the object, I would also try hard to avoid the
initialization.  C programs often don't completely initialize the object, so
the tradeoff is more complicated.)

Hans-Juergen Boehm