Re: OOC Garbage Collector Proposal

[Mike Griebling <grieblm@trt.allied.com>]

> 
> 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.

That's my assumption.  We'll probably use a technique similar to the
one Boehm's GC uses.

> 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.

I think that's understood.  When using a GC there are no guarantees.

> 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.

But all the remaining finalization procs WILL be called before the
program exits.  We have to guarantee that at least.
 
> 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

I would agree here.  First, let's get something working then we can
get more elaborate.

> 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.

It will also make native backends a bit simpler since the implementor
doesn't have to create a GC or try to port the persnickety Boehm's 
collector.

> By the way, who is doing the reference implementation of this OGC?  We

You can contact Mr. Hekkelman at the CC address.  He has volunteered
to do the reference implementation. 

> 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.

I was hoping you would volunteer for the oo2c bits.  Thanks. ;-)

Michael