Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!ucsd!ucbvax!agate!shelby!neon!lucid.com!campeau!eb From: eb@lucid.com (Eric Benson) Newsgroups: comp.lang.lisp Subject: Re: Is this the end of the lisp wave? Message-ID: Date: 24 Jan 91 21:02:54 GMT References: <17374@csli.Stanford.EDU> <1991Jan23.080259.19816@Think.COM> <17418@csli.Stanford.EDU> Sender: usenet@lucid.com Organization: Lucid, Inc, Menlo Park, CA Lines: 99 In-Reply-To: ceb@csli.Stanford.EDU's message of 24 Jan 91 16:32:03 GMT In article <17418@csli.Stanford.EDU> ceb@csli.Stanford.EDU (Charles Buckley) wrote: > In article <1991Jan23.080259.19816@Think.COM> Barry Margolin writes: > In article <17374@csli.Stanford.EDU> Charles Buckley writes: > >Exact. Makes prototyping a breeze. However, I'd still like to do my > >own storage management in Lisp when my algorithm makes that possible > >and expedient. It's simply not provided for in CL. > > I'm not sure precisely what type of extension you're referring to. Both > Symbolics and Lucid provide "resources", which are pools of objects that > can be reused rather than consing new objects each time > > But resources are nothing more than a sort of software cache of > currently unused objects belonging to an isomorphic class. If you > will, it's a sort of pointer-in-reserve system, to assure that that > which you allocated and might need again doesn't get eaten up > unnecessarily by the gc, just because you don't happen to have > explicitly programmed full pointer coverage for the life of your > algorithm. It's nothing more than a slickered-up version of the hack > that Doug Cutting replied with. > > Calling clear-resource only removes all these pointers-in-reserve, > *allowing* the gc to find the freed storage in the course of its own > plodding, methodical ruminations --- this according to language in the > vendor doc, and from my conversation with one of its employees who > should know. If I turn the gc off, calling clear-resource does me no > good - memory still gets exhausted. In those circumstances in which > gc performance is pathologically poor, the resource facility does > nothing to offload it. > > I want to be able to tell the gc "I'll let you know when I'm done with > memory, and you should manage the free chunks, consolidating and all > that, but don't bother hunting through memory for non-referenced > blocks." So the above-referenced employee: "That that would > make gc design too hard." > > Well, C runtime supports it . . . 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. In fact, many Lisp systems have this capability. Most such systems manage storage allocation so that memory returned to the system can only be used for objects of similar type, or at least of similar size, but that isn't a requirement of Lisp either. Broadly speaking, there are two main classes of storage allocation used by Lisp systems. These are 1) systems that copy all active objects to new storage and abandon the old storage to be recycled and 2) systems that retain active objects in place and link together storage used by discarded objects. Systems of the first type are used by most recent Lisp systems, especially those running on workstations with virtual memory. C runtime systems (with some exotic exceptions, such as those running on Lisp machines!) are restricted to the second type. The advantages of copying garbage collection include: - Simpler storage allocation. Allocating a new object is as simple as incrementing a pointer. - Avoids fragmentation. Non-copying collectors can cause active objects to be intermixed with free storage, resulting in difficulty allocating large objects and increased paging overhead. - Lifetime-based collection (Generation scavenging or ephemeral GC). Although it is possible to implement these with non-copying allocation, they are much simpler and more effective with a copying GC. Disadvantages include: - Copying GC consumes more of the address space, since there must be space available to copy all active objects. It is for this reason that copying GC is rarely found on systems without virtual memory, or those with small address spaces. - Copying an object requires that you find all pointers to the object and update them to the new address. In a non-copying system, it is sufficient to have one pointer to an object, since the pointer will not change. So-called "conservative" garbage collectors are generally of this type. Joel Bartlett's "mostly-copying conservative GC" is a hybrid copying/non-copying system. - It is difficult to return storage to freespace explicitly in a copying system. At the time we designed our system, we felt the advantages outweighed the disadvantages. The existence of the ephemeral GC means that the "plodding, methodical ruminations" of the collector usually don't get in your way. eb@lucid.com Eric Benson 415/329-8400 x5523 Lucid, Inc. Telex 3791739 LUCID 707 Laurel Street Fax 415/329-8480 Menlo Park, CA 94025