Newsgroups: alt.lang.design,comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.lang.ada
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Message-ID: <hbakerD026uL.HIz@netcom.com>
Organization: nil
References: <3be0mh$1p7@gamma.ois.com> <3bfprn$okr@scipio.cyberstore.ca> <3bg6ci$18k@gamma.ois.com>
Date: Wed, 30 Nov 1994 02:27:57 GMT
Lines: 26
Xref: glinda.oz.cs.cmu.edu comp.lang.c:118404 comp.lang.c++:100918 comp.lang.lisp:15861 comp.lang.ada:24180

In article <3bg6ci$18k@gamma.ois.com> beckwb@ois.com (R. William Beckwith) writes:
>An incr/decr only occurs when there is a change to the graph of
>objects.  If the graph does not change, then there is not need
>to incr/decr the counts.

This is fine, so long as every object is 'nailed down' directly or
indirectly to a root somewhere.  A problem occurs with newly allocated
objects that someone forgets to nail down, or forgets to deallocate it
after deciding _not_ to keep it.  A similar problem occurs when an
object is being destroyed, and it has been unhooked, but due to some
condition -- e.g., an error -- the program forgets to deallocate it.

An analogous situation happens in some GC systems -- e.g., Kyoto
Common Lisp.  If a compiled function returns a newly allocated object
which is then used as an argument to another compiled function which
then allocates storage, the GC can recycle the object, because it was
never 'nailed down' -- e.g., by storing a reference to it in the
run-time stack.  For this reason, one must used 'object' declarations
with some care in compiled code.

Henry Baker
Read (192.100.81.1) ftp.netcom.com:/pub/hb/hbaker/README for ftp-able papers.
WWW archive: ftp://ftp.netcom.com/pub/hb/hbaker/home.html
************* Note change of address ^^^        ^^^^


