Linux and GC

[Scott L. Burson]

   Date: Tue, 28 Apr 1998 23:41:53 +0100
   From: "Alaric B. Williams" <abw97@doc.ic.ac.uk>

   Kragen wrote:

   > This is a way of doing incremental GC that seems to avoid most of the
   > hairy problems incremental GC usually has.  The parent and child need
   > only share some small communication window though which they can talk
   > about garbage; when the child finishes, it can exit.

   > What are some disadvantages of this method?

   It's known in the literature as using a "write barrier", IIRC... it's
   been studied already with some success, I think.
    
The technique Kragen suggests may have been studied, although I don't think I
had heard of it, but it's not what's called a "write barrier".  A write
barrier is a piece of code or possibly hardware that detects writes of
pointers into memory having certain properties: roughly, where the cell into
which the pointer is written will not be scanned (again) during the current
collection, but the object to which the pointer points has not been marked as
live.  A write barrier is needed in both fully incremental collectors, such as
the Lisp machine's, as well as semi-incremental collectors (a term I just made
up to cover collectors, such as Allegro's, that run uninterruptibly during a
collection but scan and collect only a small amount of memory each time).

Kragen's suggestion is an intriguing one.  I'd have to think about it for a
while to understand the tradeoffs.

-- Scott