Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!scramble.lm.com!nntp1.jpl.nasa.gov!news.magicnet.net!news.sprintlink.net!news-fw-6.sprintlink.net!news.sprintlink.net!new-news.sprintlink.net!news.sgi.com!swrinde!cs.utexas.edu!howland.erols.net!netcom.com!hbaker
From: hbaker@netcom.com (Henry Baker)
Subject: Re: Real-time garbage collection in Scheme?
Content-Type: text/plain; charset=ISO-8859-1
Message-ID: <hbaker-0808961552330001@10.0.2.1>
Sender: hbaker@netcom19.netcom.com
Content-Transfer-Encoding: 8bit
Organization: nil
X-Newsreader: Yet Another NewsWatcher 2.2.0
References: <31FFC897.76B8@cnmat.berkeley.edu> <hbaker-0408960727110001@10.0.2.15> <4u80nn$jb2@roar.cs.utexas.edu> <hbaker-0708960515490001@10.0.2.1> <4uao61$ooj@roar.cs.utexas.edu>
Mime-Version: 1.0
Date: Thu, 8 Aug 1996 23:52:33 GMT
Lines: 84

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

> In article <hbaker-0708960515490001@10.0.2.1> you write:
> >In article <4u80nn$jb2@roar.cs.utexas.edu>, wilson@cs.utexas.edu (Paul
> >Wilson) wrote:
> >> In article <hbaker-0408960727110001@10.0.2.15>,
> >> Henry Baker <hbaker@netcom.com> wrote:
> >> >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.
> 
> But then just about any GC is hard real-time, including a simple 
> stop-and-collect collector.  The delay for any given program operation
> may be large, but it's it's generally bounded by things like the total
> size of memory.

That's what I get for trying to be succinct.  Of course, 'a priori' here
means 'independent of both total memory size and number of live nodes' --
i.e., the _a priori_ bound is given _before_ the memory size and number of
live nodes is given.

> More importantly, I think there's plenty of precedent in the real-time
> literature for a stricter notion of hard real time.  The main definition
> of hard real time is "able to reliably meet deadlines" or something like
> that, and the "bounded latency for individual operations" is just a
> sloppy shorthand for that.

You are correct that 'hard real-time' often means ability to meet strict
deadlines with an infinite penalty.  'Soft' real-time means that a deadline
can be missed, but with some finite penalty -- e.g., missing a deadline
by a little bit in a Nyquist-like sampling system will increase the
jitter-related noise, which may be acceptable if the system has some
noise budget.

The use of 'hard real-time' in conjunction with GC comes more from the
automata world, where one automaton is emulated by another in 'real time',
if the steps of the emulated machine can be correlated with the emulating
machine in a relatively rigid way -- e.g., perhaps by inserting padding
to make sure that the emulated machine runs _exactly_ k times slower than
the emulating machine.

Clearly, unless you have an actual task to do, rather than simply emulating
another machine, it is difficult to talk about meeting particular deadlines.

> For example, when people talk about real-time thread scheduling, they
> generally do *not* use a bounded-latency-per-operation as the criterion
> for real time.  If you had a thread scheduler that guaranteed no
> more than 1ms interruptions, but did that every nanosecond of thread
> time, it would not be considered a real-time thread system.

You want a concept which might be called something like 'amortized real
time' or some such.  The theory people who work with manipulations on
search trees (e.g., Tarjan) talk about 'cost amortization' over a number of
steps of the algorithm.

> I think it's best to view GC's similarly---an incremental GC implicitly
> incorporates a thread scheduler, because it interleaves the mutator
> thread(s) with the tracer thread(s), even if that may actually be
> implemented ad-hoc coroutining rather than actual threads.  Viewed
> that way, which clarifies the real issues, my interpretation of
> "hard real-time" is solidly mainstream. 

You are confusing the specific technical phrase 'hard real time' with
the generic notion of 'real time'.  People in the 'real time' community
talk about all sorts of notions, and you usually have to read more than
one of their papers before you can figure out what _their_ notion really
is.  :-) :-)

I agree that the current notion of 'real-time GC' does not incorporate your
more strict, and for many purposes more useful, notion of 'real time'.  So
let's use this occasion to define a new term.

Not-so-memorable suggestions:

'deadline real-time GC'
'amortized real-time GC'
...

Additional suggestions are hereby solicited...

Note that you are looking for a more-or-less 'scale-independent' notion, since
meeting deadlines at one scale is not sufficient to meet deadlines at all
other scales.
