Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!godot.cc.duq.edu!newsgate.duke.edu!news.mathworks.com!news-res.gsl.net!news.gsl.net!ix.netcom.com!netcom.net.uk!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: Real-time garbage collection in Scheme?
Message-ID: <hbaker-0408960727110001@10.0.2.15>
Sender: hbaker@netcom12.netcom.com
Organization: nil
References: <31FFC897.76B8@cnmat.berkeley.edu> <31FFD0C5.17C9@ccm.hf.intel.com> <4tqj38$r35@roar.cs.utexas.edu>
Date: Sun, 4 Aug 1996 15:27:11 GMT
Lines: 26

In article <4tqj38$r35@roar.cs.utexas.edu>, wilson@cs.utexas.edu (Paul
Wilson) wrote:

> One thing that you should be aware of is that Baker-style incremental
> GC's are *not* hard real-time.  They can have big slowdowns right
> after a GC starts, where the individual pauses are tiny but there
> are so many of them that your throughput goes down by an order of
> magnitude or more, even with specialized hardware support.  So the
> individual pause times are bounded, but you miss your deadlines anyway.

It is true that right after a flip, a large number of objects may be
copied.  However, whether you call this a 'slowndown', or the behavior
just before a flip a 'speedup/optimization' is purely semantical.  In
any case, since the definition of 'hard' 'real-time' is 'a priori bounded
latency', and _not_ throughput, the Baker-style incremental GC's _are_
'hard real-time' GC's.

At the cost of an additional pointer/object and an additional indirection,
the Brooks 'optimization' can decouple copying so that it may be scheduled
a bit more smoothly.  Indeed, several papers have pointed out that
one can promptly&quickly _allocate_ the space for the new object, and then
copy it 'lazily' at one's leisure, assuming that the object can be continually
an unambiguously referenced even in the middle of its being copied.

For some purposes, and for implementation in languages such as C/Ada/etc.,
'treadmill' collectors may be more appropriate.
