Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: Memory Management in Lisp?
Message-ID: <1991Feb19.030719.1137@Think.COM>
Date: 19 Feb 91 03:07:19 GMT
References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM> <1991Feb18.191549.7575@aero.org>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 36

In article <1991Feb18.191549.7575@aero.org> srt@aero.org (Scott "TCB" Turner) writes:
>I haven't really given it much thought.  But it has always seemed
>strange to me that Lisp in general gives little control over memory
>management to the user, when it is so obviously critical to system
>performance.

Traditionally, one of the most important differences between Lisp and most
other languages has been the fact that memory management is automatic.
Even EVAL isn't as fundamental to Lisp as I once thought, since Scheme
doesn't have it (although many *implementations* of Scheme add it as an
extension), but it does have automatic memory management.

>I've been thinking about the subject since my original post, and one
>facility I think might be interesting is a garbage collection advisor.
>Currently gc collects an object if it has no references.  The idea
>here is to let gc collect an object if the (user-supplied) advisor
>predicate returns true.

An interesting idea, but potentially very dangerous.  An object may have
references that the application isn't aware of.  For instance, the user
could have assigned an object to a global variable while in the debugger.
Or in a Dynamic Windows or CLIM environment, just printing out the object
creates a new reference to the object from the window's output history
structure.

A similar caveat could be made about objects allocated on the stack (as
ANSI CL will permit, using the DYNAMIC-EXTENT declaration).  However, in
this case, the routine that saves away the value could check whether it is
stack-allocated, and move it to the heap first (that's what Dynamic Windows
does).  However, in your example, the GC advisor runs *after* the reference
has been made.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar