Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!shelby!csli!ceb
From: ceb@csli.Stanford.EDU (Charles Buckley)
Newsgroups: comp.lang.lisp
Subject: Re: Industrial Strength Lisp GC's (was: end of the lisp wave?)
Summary: ISLGC's admitted as flawed, new strategy required (esp. for multis)
Message-ID: <17448@csli.Stanford.EDU>
Date: 26 Jan 91 03:08:58 GMT
References: <NETMAILR11011708110SEB1525@MVS.DRAPER.COM>
	<17374@csli.Stanford.EDU> <1991Jan23.080259.19816@Think.COM>
	<17418@csli.Stanford.EDU> <EB.91Jan24130254@hardwick.lucid.com>
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 64
In-reply-to: eb@lucid.com's message of 24 Jan 91 21:02:54 GMT

In article <EB.91Jan24130254@hardwick.lucid.com> eb@lucid.com (Eric Benson) writes:

   From: eb@lucid.com (Eric Benson)
   Newsgroups: comp.lang.lisp

   In article <17418@csli.Stanford.EDU> ceb@csli.Stanford.EDU (Charles Buckley) wrote:

   <thread about wanting to do my own memory management in Lisp, and 
    how this isn't possible with a commercial CL offered by a major
    vendor.  eb is an employee of a major CL vendor>

   I don't know whether the vendor you are referring to is Lucid, but the
   description matches our system.  It is true that there is no way for
   the user to explicitly return storage to Lisp's free space so that it
   can be used without garbage collecting.  This is a consequence of the
   design of our storage allocator.  We could have designed it so that
   this operation would be possible, but we felt other factors outweighed
   the need for this capability. 

Let's assume it was Lucid, since you confessed, and that's a product
over which you exercise some influence.  Anyway, Lucid certainly have
heaps of market share, and therefore can generate lots of garbage (to
collect).

   <eb's really succinct and clear review of the state-of-the-art in
    commercially available garbage collection deleted, but keeping 
    back:>

     . . .  Joel Bartlett's "mostly-copying
     conservative GC" is a hybrid copying/non-copying system.

   <and>

   - It is difficult to return storage to freespace explicitly in a
     copying system.

   <which Lucid use>

Thanks for a well-written posting on garbage collection.  You seem
implicitly to agree that there's still room for improvement in terms
of what's delivered with commercial Lisps, there's some substance
to the many complaints and grumblings, and this is not a time to rest
on one's laurels.

   . . . .   The existence of the ephemeral GC means that the
   "plodding, methodical ruminations" of the collector usually don't get
   in your way.

Ah, but making available ephemeral collecting only helps when you're
running things which should ideally be interactive, like communing in
a `terminal-high' with the last cry in these graphics-laden,
memory-hungry, object-oriented universal knowledge representation
schemes so popular of late.  Once you start to do serious
calculations, the ephemeral GC becomes ephemeral in effectiveness, and
the time bite the dynamic collector takes can noticeably influence
benchmarks.  When its parameters are badly tuned, it can make life
miserable.  Not to give the user the opportunity to do his/her own
when s/he knows what to do leads to having Lisp not be taken
seriously.

Anyway, these days, I'd probably combine garbage collection with object
migration among non-shared memory processing nodes on a multi-, which
would really skew your design criteria away from strategies employed
in present-day copying GCs.