Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp,connect.audit
Subject: Re: Memory Management in Lisp?
Message-ID: <1991Feb21.102925.25226@Think.COM>
Date: 21 Feb 91 10:29:25 GMT
References: <1991Feb20.150947.2039@ibmpcug.co.uk>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 30

In article <1991Feb20.150947.2039@ibmpcug.co.uk> bill@ibmpcug.co.uk (Bill Birch) writes:
>> An interesting idea, but potentially very dangerous.  An object may have
>> references that the application isn't aware of.
>This is a function of the way garbage collection is arranged. A mark-
>sweep system has problems with the above.However, in a reference-
>counting LISP system, the total number of references to any object is
>known by definition. Thus it is possible to allow the application
>to garbage collect explicitly. 

If the application checks the reference counts, it is duplicating the
function of the regular garbage collector, so what's the benefit?  I was
responding to a proposal for a mechanism where the application could say to
the system, "ignore whatever you think the state of this object is -- I
know a priori that it is garbage."  In a reference count system, I assume
this would be a function that sets the reference count of the object to
zero, and decrements the reference counts of the objects that it
references.

I suppose the application could check whether the object's reference count
is higher than it expects, and assume that this indicates that there are
"extra" references, in which case it shouldn't forcibly GC it.  But I
believe that an application that knows the expected reference counts
exactly probably also knows where the references come from, so it would be
just as easy to set those references to NIL, which will cause the reference
counts to decrement.
--
Barry Margolin, Thinking Machines Corp.

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