Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!rpi!crdgw1!excelan!leadsv!pyramid!decwrl!hplabs!unix!Teknowledge.COM!polya!shelby!agate!apple!brutus.cs.uiuc.edu!wuarchive!wugate!uunet!snorkelwacker!ai-lab!caroma
From: caroma@wheaties.ai.mit.edu (Carl R. Manning)
Newsgroups: comp.lang.lisp
Subject: Re: LISP compiler? (really future of MACL) (Really Incremental GC)
Summary: Ref for the Opportunistic Garbage Collector
Keywords: GC
Message-ID: <5145@whea?TI-chex.ai.mit.edu>
Date: 27 Nov 89 19:17:38 GMT
References: <5130@internal.Apple.COM> <5149@internal.Apple.COM> <616@pyuxf.UUCP> <2159@cs-spool.calgary.UUCP> <4@wglen.UUCP>
Reply-To: CarlManning@ai.mit.edu
Organization: The MIT AI Lab, Cambridge, MA
Lines: 25

In article <4@wglen.UUCP> bonham@wglen.UUCP (Mike Bonham) writes:
>...if an
>application involves an interactive user interface (as many Lisp programs
>do!!!), then incremental GC can greatly improve the *perceived* responsiveness.
>...
>-- Mike Bonham       CPSC.UCalgary.CA!wglen!bonham
>-- 
If you're just dealing with human interfaces rather than real time
requirements, then incremental garbage collection isn't the only way
to improve perceived performance --- instead you can try to schedule the long
scavenges during otherwise unresponsive periods, e.g. during
compute-bound operations or during idle periods.  For more on this idea,
see Section 4: Scavenge Scheduling, (p 29) of: 

   Design of the Opportunistic Garbage Collector
   Paul R. Wilson and Thomas G. Moher
   OOPSLA'89 Proceedings, 1-6 October, 1989
   SIGPLAN Notices vol24 n10, p 23-35

(This paper also includes some other ideas for implementing
generational GC on stock hardware and some performance measurements.)

(Just passing on a reference -- I have no experience using it.)

CarlManning@ai.mit.ed