[Oberon] Garbage Collection in Aos

[Paul Reed]

> From: Pieter Muller <pieter.muller at alumni.ethz.ch>
> > ...tasks would need to be prohibited from doing anything that would affect
> > the heap.  I would imagine
> > that there is a large class of RT problems
> > that could be handled this way, but this
> > would require much programming discipline.
> > But I agree, implementing an incremental GC
> > is the best overall solution.
> 
> Even worse, such tasks are not allowed to *use* pointers, since the GC
> modifies all pointers while traversing the heap.  This is due to the
> pointer rotation algorithm.

Yes, I forgot this recently when I made changes to my
GC to support walking the stack - duh-oh!.  And I forgot 
that I had made an assumption about pointers only pointing to
the beginning of heap blocks, rather than anywhere in
their interior - duh-oh again!.  But the great thing about 
the Schorr-Waite algorithm is that it is beautifully simple, 
although apparently not simple enough for me... :)

Pointers are only reversed inside complex structures, so
if you had a root variable which pointed directly to a flat
buffer, the buffer would be marked, the traversal of
pointers would be complete, and GC would move on to the next 
root. If at interrupt time, the notion of a "current buffer" 
was used but not changed, that would be ok.

If you have buffers in a doubly-linked list, you could go
one way with Oberon pointers and the other way with SYSTEM.ADRs.
Sounds kludgy, but we are talking about device-driver-land.
If buffers are in a least-recently-used list, this may in fact
make even more sense.

Oberon's module list and file list use untyped pointers to
side-step the GC.  It may be that untyped pointers are actually 
used anyway from time to time, if they are referred to at the 
lowest level by hand-optimised machine code... :)

The original Oberon system shows that careful design under a 
partly-restrictive set of criteria can lead to dramatically 
reduced complexity of the entire system.  I am happy to take
extra care when writing device drivers if it means that the
system ends up being simpler as a whole.

Paul Reed