Newsgroups: comp.lang.dylan,comp.lang.lisp,comp.lang.java
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.sprintlink.net!howland.reston.ans.net!ix.netcom.com!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: Garbage collection cost (was Re: Parenthesized syntax challenge)
Message-ID: <hbaker-1810951331360001@10.0.2.15>
Sender: hbaker@netcom22.netcom.com
Organization: nil organization
References: <44aa9a$j5h@miso.cs.uq.edu.au> <DGJp8o.7nF@Cadence.COM> <MAD.95Oct18040436@tanzanite.math.keio.ac.jp> <hbaker-1710952127200001@10.0.2.15> <462tdh$6n3@jive.cs.utexas.edu>
Date: Wed, 18 Oct 1995 21:31:36 GMT
Lines: 31
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5474 comp.lang.lisp:19589 comp.lang.java:2032

In article <462tdh$6n3@jive.cs.utexas.edu>, wilson@cs.utexas.edu (Paul
Wilson) wrote:

>    With a copying GC, you can lose big if the live data barely fit in
> RAM and most of them don't die---you're likely to nearly double your
> footprint toward the end of GC, when you have all of the old versions
> and most of the new versions around.  If the live data barely fit in
> RAM before, they definitely won't toward the end of GC.  You'll page
> a lot.  Locality in the GC process may mean that it'll mostly be
> bandwidth-limited rather than latency (seek) limited, but it'll still
> be expensive.

The major source of 'random' accesses to fromspace is looking up forwarding
addresses.  I claim that the use of a forwarding address cache would
eliminate a lot, if not most, of these accesses.  As I said before, if
one is simply copying stuff in the same order, then the (non-forwarding)
accesses to fromspace are very well behaved.

----

If real memory is that limited, then I would strongly suggest using some
sort of 'RamDoubler' type of VM compressor.  This should work _very_ well
with either a mark/sweep or a copying collector, but would require a bit
of additional effort to make sure that true 'garbage' is zeroed so that it
doesn't take much real memory when compressed.  Under these conditions,
I believe that the real footprint of mark/sweep and copying collectors
would become even closer.

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
