EROS and GC

[Jonathan S. Shapiro]

> > EROS does not have a garbage collector. The security implications of an
> > object that can examine all other objects are not pretty. Also, disk GC
is
> > not as nice as memory GC for reasons of latency.
>
> In this case, would explicit reference counting be a good general
convention
> for objects with a limited lifecycle?

I'm inclined to think not, though I have to say at the beginning that the
answer isn't at all obvious.

First, it is an architectural principle that the presence of the kernel is
not visible to applications. The kernel implements certain objects, but it
always behaves in response to capability invocations, and then always in a
way that can be accounted for without appealing to "magic" state that is
maintained in the kernel. The checkpoint mechanism is the biggest exception,
but this is not visible to applications except in special cases.

For example, a careful examination of the IPC spec will reveal that there
are no possible errors that can arise from kernel resource starvation. The
data either moves or it doesn't. All possible errors arise from application
misbehavior.

Similarly, it would not be appropriate for some magic system entity to
initiate destruction of unreferenced objects.

Beyond whether it's a good idea, not all objects are destroyable and the
order code used to request self-destruction is a convention, not a
guarantee.

In practice, however, GC may not be necessary. If one object is subordinate
to another, the dominant one can request the subordinate one to destroy
itself as part of the dominant object's destroy logic.  While there will be
buggy cases, in the end it tends to be the case that the entire subsystem
was built out of a single space bank, and shooting that space bank has a way
of reclaiming everything.

One reason that explicit storage allocation in C is a pain is that it is
inadequately flexible about building and reclaiming storage pools.