[Oberon] Garbage Collection in Aos
paulreed at paddedcell.com
Wed Feb 12 11:12:17 CET 2003
> 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.
More information about the Oberon