Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!haven!decuac!e2big.mko.dec.com!bacchus.pa.dec.com!decwrl!ucbvax!bloom-beacon!UICBERT.EECS.UIC.EDU!wilson
From: wilson@UICBERT.EECS.UIC.EDU (Paul Wilson)
Newsgroups: comp.lang.scheme
Subject: Re: what makes scheme?
Message-ID: <9008111702.AA06156@uicbert.eecs.uic.edu>
Date: 11 Aug 90 17:02:28 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 26

Oliver's comment about stop-and-copy and locality seems off the mark.

If Elk uses simple stop-and-copy, its locality is bound to be very
poor, so heap size matters a lot.  A stop-and-copy collector does
compact the data at every gc, but between gc's it touches every
location in the space being allocated.  (It writes to them all, too,
so all those pages have to be written back to disk as well as paged
in the first place.)

A simple semispace copy collector writes to every location in the heap
every two gc cycles.  What you need is a generational collector if you
want good locality.


This may be unnecessary for programs that don't do a whole lot of allocation,
and which never have much live data at any one time;  you may just be able
to get away with making your heap size really small.  But you will touch
every location in that heap in a highly regular and repetitious fashion.

  -- Paul


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