GC'd capabilities shapj@us.ibm.com
Thu, 15 Jul 1999 14:30:55 -0400

I'm clearing my whiteboard, and want to get a couple of ideas into the archive. These originated with Mark Miller.

Mark and I were talking about using GC in the context of EROS, and the semantic implications thereof. We originally were talking about using GC strictly for in-memory objects, but then generalized to the question of general GC as a means of lost storage recovery.

Mind you, I'm of the "you pay for it, you lose it, you lost it" school, but it never hurts to explore the options.

There is a design question and a consequential issue.

The design question is whether reclaimed storage reverts to the prime bank or to the bank from which it was allocated. If it reverts to the prime bank, the logic is "you lose it and the system as a whole gets it back" If it reverts to the bank that allocated it, the logic is "the owning bank gets the space back when the last capability to it goes away."

Either is feasible, but there is a covert channel issue: the release of the last capability now becomes observable by other parties, including the allocator.

Mark also points out that checkpoints are a natural time to perform an in-memory GC (generationally) on objects allocated during the window of operation covered by the last checkpoint.

Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595