Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.lang.modula3
Subject: Re: GC references (was RE: Two Oberon questions)
Message-ID: <12272@exodus.Eng.Sun.COM>
Date: 26 Apr 91 00:01:26 GMT
References: <91Apr23.113622pdt.16245@alpha.xerox.com> <1991Apr25.130634.19780@jyu.fi>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 31

sakkinen@jytko.jyu.fi (Markku Sakkinen) writes:
>One very important disadvantage of copying collection is that it
>restricts the possible semantics of objects:  no finalisation
>(destructors, as in C++) is possible.

Finalisation is possible with copying collection, though it is not
pretty.  The game played is somewhat like the game played to implement
"weak pointers".

Registering a pointer for finalisation is implemented by hiding it on
a list (hidden by its encoding, or hidden by design).  At a
collection, assume that all the live pointers have been forwarded.  At
this point, traverse the list of finalizable objects.  Each pointer
stored there is either forwarded, or about to die.  All the sickly
pointers are placed on another list, and the objects that they
reference are copied into new space.  Of course, these objects may
reference other objects, etc.

At this point, you've got a couple of choices based on how you feel
about cyclic and shared finalisable garbage.  The easy answer is to
declare that it is all going to die, and to finalise everything on the
"sickly list".  The hard answer is to assume that finalisation might
alter the accessibility of memory (e.g., "global_variable :=
my_component"), and proceed accordingly.  Except for cycles, even this
can be dealt with, though it is painful (find the roots of the
finalisable garbage graph, finalise them, put everything else back on
the finalisable list, wait till next collection).

One hopes that better algorithms to do this exist, but it is possible.

David