Re: OOC Garbage Collector Proposal

[Michael van Acken <mvacken@t-online.de>]

Mark> Since markStack = FALSE can be unsafe, (i.e., a programmer can specify
Mark> markStack = FALSE when in fact there are objects anchored on the stack),
Mark> I would vote to eliminate the parameter and always scan the stack:
Mark> 
Mark>    PROCEDURE GC ();  (* to explicitly invoke GC *)
Mark> 
Mark> It is more in keeping with the philosophy of garbage collection and I
Mark> am not confident that I would know when there aren't any objects
Mark> anchored on the stack without being an expert on OOC. (Perhaps it is
Mark> possible for the compiler and collector to determine when it is safe
Mark> to perform this optimization?)

I don't think there is a way to assert that there are no pointers on
the stack that would work well in practice.  So the stack contents can
never be discarded completetly.  On the other hand the programmer
might believe that there are no pointers to live objects on the stack
that can't be reached through globale module variables.  My guess is
that such a situation is rather common.  But as you said: it's not
safe.

How does one scan the stack for pointers in an Unix environment?  I
doubt that any OOC compiler can give exact information on the stack
layout at any given time during program execution.  So pointers on the
stack have to be identified without any convenient support form the
compiler.

Mike> As well, the following are needed to support finalization:
Mike> 
Mike>   TYPE
Mike>    Finalizer = PROCEDURE (obj: SYSTEM.ADDRESS);
Mike> 
Mike>   PROCEDURE RegisterFin (obj: SYSTEM.ADDRESS; finalize: Finalizer);
Mike>   PROCEDURE FinalizeAll ();
Mike> 
Mike> The FinalizeAll procedure would be implicitly called at the end of
Mike> a main program.

Two things I would like to add here:
a) There is no guarantee that finalization procs are called in a
particular order.  A finalized object cannot expect that the
finalization procs for all the objects it is pointing to have been
called beforehand.
b) There is no guarantee that a finalization proc is called ever, even
if the object becomes freeable.  The rationale here is that a program
behaves the same way for all garbage collectors, including the "empty"
gc.

Mark> Having thought about it more, I do think that having GC occur during
Mark> I/O is a good idea (if we spawn off I/O as a separate thread so that
Mark> I/O and GC proceed in parallel). That thread of the application is
Mark> waiting anyway and so GC latency can be hidden. I still think it
Mark> better to leave GC explicit though. Perhaps it is a bias resulting
Mark> from my understanding of the Oberon philosophy of making everything
Mark> explicit and understandable. Perhaps it is a bias fostered by being
Mark> bitten with hidden gotchas in other systems.

I think it's a bit premature to talk about threaded gc.  As for gc
when waiting for user input: I think the old Oberon V4 (probably not
the current implementations) used a very pragmatic approach.  It would
_only_ do gc after a number of iterations of the top-level event loop.
Only in this case it was asserted that the stack had no pointers.
A simple and very efficient approach.  Too simple, of course, if you
have commands that need to gc during their execution.

Brian> Nonetheless, a portable Oberon-2 collector would be a great idea, if
Brian> only to reduce our dependency on someone else's C code for ports. You
Brian> would have to be extra careful when using external code when you have
Brian> precise GC, but the efficiency benefits would be worth it. I think a
Brian> collector like the one used by BlackBox that allocates multiple heaps
Brian> as needed (or does it expand and contract one heap?) would help.

I agree.  No implementation of Oberon is complete without a garbage
collector.  Boehm's gc is the only alternative for oo2c (there is no
replacement as portable or stable), but a native implementation should
stand on its own feet here.

By the way, who is doing the reference implementation of this OGC?  We
need a working prototype and some experimental results with OOC.  For
my part I volunteer to provide the necessary compiler support in oo2c
for such a prototype.

-- mva