Re: Garbage Collection and Interactive Languages

eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig) writes:
>[Some models of garbage collection assume that it can only occur during
>an "allocate storage" call, while others have to assume that it can occur
>at any time due to interrupts or multiple CPUs. In the second model ...]


>generating correct code is very difficult, since one can't put
>pointers to heap objects in registers, since garbage collection might
>occur between the address-loading instruction and the address use. Under
>this model, one usually has to divide the registers into two groups, one
>holding only pointers to heap objects and one holding only integers; this
>way, the collector can examine and modify the machine registers knowing
>how to interpret their contents. This is an appropriate model to use
>where the collector is, say, part of the operating system and is running
>in parallel with the mutator. (The Symbolics 3600, for example.)


This model also makes sense under very different conditions. It's used
by the Xerox Portable Common Runtime, for example. It can be hard to
collect only in a nice state. A check per basic block is not free. And in
a multi-threaded world, it may be nontrivial to implement thread
single-stepping. And if you use a collector that conservatively scans
at least the stack and registers, and doesn't move objects referenced by
them, it's not very hard to generate code for this model. In fact,
C compilers do it by accident at least 99.999% of the time.




Hans-J. Boehm
(boehm@parc.xerox.com)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.