> 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.
>
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.
For example I have an interpreter
that allows the programmer to read the reference count of an object.
Also , to force collection of an unused tree hanging off a symbol can
simply be done by : (SETQ FOOBAR NIL)
Since the reference count on
the contents of FOOBAR will have dropped to zero, the memory
is automatically reclaimed.
Bill
--
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
--
In article <·····················@ibmpcug.co.uk> ····@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.
······@think.com
{uunet,harvard}!think!barmar
In article <······················@Think.COM>, ······@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
········@leland.stanford.edu