Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!purdue!decwrl!shelby!neon!carcoar!wilson
From: wilson@carcoar.Stanford.EDU (Paul Wilson)
Newsgroups: comp.lang.lisp
Subject: Re: LISP compiler? (really future of MACL)
Message-ID: <1989Dec6.221540.17239@Neon.Stanford.EDU>
Date: 6 Dec 89 22:15:40 GMT
References: <5130@internal.Apple.COM> <5149@internal.Apple.COM> <616@pyuxf.UUCP> <5117@tekcrl.LABS.TEK.COM> <2203@cs-spool.calgary.UUCP>
Sender: USENET News System <news@Neon.Stanford.EDU>
Reply-To: wilson@carcoar.Stanford.EDU (Paul Wilson)
Organization: U. of Illinois at Chicago (UIC, *not* UofC or UIUC)
Lines: 33

In article <2203@cs-spool.calgary.UUCP> gintera@cpsc.ucalgary.ca (Andrew Ginter) writes:
>In article <5117@tekcrl.LABS.TEK.COM>, Ken Dickey writes:
>> > A real time (parallel or incremental) garbage collector is roughly
>> > twice as costly as a comparable stop-and-collect collector ...
>>
>> This is not the case if you use your VM hardware.  See "Real-time
>> Concurrent Collection on Stock Multiprocessors" by Appel, Ellis, &
>> Lee; Princeton U. tech. report: CS-TR-133-88.
>
>Appel, Ellis & Li's technique reduces the cost of checking for
>forwarding pointers.  It does nothing to address the performance
>penalty associated with the increased frequency of garbage collection
>in a real time or incremental system (Philip L. Waldler, CACM, Sept/76).
>Waldler concludes that parallel collectors consume twice the resources
>of serial collectors, almost all of the time, even when using algorithms
>without any forwarding pointers.

  Maybe not.  You need more memory, sure, but it doesn't have to be real
  memory.  The locality characteristics of garbage-collected systems
  are pretty strange, and you can use an incremental garbage collector
  to *improve* locality dynamically.  (See Jon L. White's paper on
  the basic idea in the 1980 Lisp conference proceedings, and Bob
  Courts' incorporation of this principle into a generational gc 
  [CACM, Sept. 88].)

  I'm not saying incremental gc's are cheap, but I'm pretty sure
  nobody's done all of the relevant experiments.


Paul R. Wilson                         
Software Systems Laboratory               lab ph.: (312) 996-9216
U. of Illin. at C. EECS Dept. (M/C 154)   wilson@carcoar.stanford.edu
Box 4348   Chicago,IL 60680