Re: Ada GC and a bunch of other stuff

<dave@occl-cam.demon.co.uk> wrote:


> With a Mark-and-Sweep GCs we arrange to know the types and know the
> sufficient set of pointers into the heap from the stack...
> GC occurs at a well-defined point and it is easy to
> arrange that the primary pointers are comfortably stacked...
> Yes we do need to be carefull about safely
> initialising storage with pointers in them...
> No, we do not
> need to scavenge pointers from floating point registers or worry about
> intermediate address computations. And yes you do need some feedback
> between the dead-code eliminator and the heap reference manager -
> essentially any pointer in scope can be accessed by the GC
> 'asynchronously' to the normal program flow.


[good stuff snipped]


Why not treat the GC as an asynchronous thread -- that the compiler
knows about -- that has access to (most of) the live data structures?
If this is done right, many of the problems of initialization and
'dead code' elimination go away, because the compiler is now aware
that stuff has to be dead from both the main process _and_ the GC
process before it can be eliminated. So if your compiler does threads
correctly, then it should be able to do GC correctly.


One must decide what the 'sequence/synchronization' points are,
however. In most of my work, I force these points to be the points of
allocation -- e.g., any CONS may do some GC work. Some systems --
e.g., the MIT Lisp Machine -- have certain kinds of CONSing during
which the GC is known to be off. Equivalently, the programmer may
temporarily turn off/lock out/deschedule the GC, but in such a way
that compiler is aware of this. However, this should only be done for
a priori bounded amounts of allocation.


The GC process has access to GC-collectible stuff. Explicitly-managed
stuff -- like 'linear/unique' types -- can be hidden from the GC, _so
long as they can never reference GCable stuff_.


The same idea works for handling database recovery. The recovery
'process' is another asynchronous 'thread' that runs at (in)opportune
times. (After all, what are programs like 'fscheck', but GC's for the
file system/db ?)


--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
--

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