Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker.mit.edu!shelby!leland.Stanford.EDU!news
From: alderson@leland.stanford.edu (Rich Alderson)
Newsgroups: comp.lang.lisp,connect.audit
Subject: Re: Memory Management in Lisp?
Message-ID: <1991Mar1.033204.5224@leland.Stanford.EDU>
Date: 1 Mar 91 03:32:04 GMT
References: <1991Feb20.150947.2039@ibmpcug.co.uk> <1991Feb21.102925.25226@Think.COM>
Sender: news@leland.Stanford.EDU (Mr News)
Reply-To: alderson@leland.stanford.edu (Rich Alderson)
Followup-To: comp.lang.lisp
Organization: Stanford University Academic Information Resources
Lines: 16
In-Reply-To: barmar@think.com (Barry Margolin)

In article <1991Feb21.102925.25226@Think.COM>, barmar@think (Barry Margolin) writes:
>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.

Interesting.  I read the suggestion the other way:  That GC might think an
object was garbage, but should leave the object alone unless the advisor said
GC could reap it.  That was in tune with the idea of explicitly re-using
objects rather than letting them be GCed.

Rich Alderson
alderson@leland.stanford.edu