ceb@csli.Stanford.EDU (Charles Buckley) (01/26/91)
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.