From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Date: Wed, 30 Nov 1994 02:27:57 GMT
Date: 1994-11-30T02:27:57+00:00 [thread overview]
Message-ID: <hbakerD026uL.HIz@netcom.com> (raw)
In-Reply-To: 3bg6ci$18k@gamma.ois.com
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 ^^^ ^^^^
next prev parent reply other threads:[~1994-11-30 2:27 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CzHCvp.9rM@rheged.dircon.co.uk>
[not found] ` <TFB.94Nov21091959@burns.cogsci.ed.ac.uk>
[not found] ` <RFB.94Nov27213114@cfdevx1.lehman.com>
[not found] ` <3be0mh$1p7@gamma.ois.com>
[not found] ` <3bfprn$okr@scipio.cyberstore.ca>
1994-11-29 21:27 ` Reference Counting (was Re: Searching Method for Incremental Garbage Collection) R. William Beckwith
1994-11-30 2:27 ` Henry G. Baker [this message]
[not found] ` <DAG.94Nov30090717@bellman.control.lth.se>
1994-11-30 16:39 ` David Weller
1994-11-30 17:58 ` Erik Naggum
1994-11-30 23:14 ` Michael Feldman
1994-12-09 14:19 ` Ada 95 is the name Tucker Taft
1994-12-09 22:33 ` Pat Rogers
1994-12-11 18:59 ` Jean D. Ichbiah
1994-12-11 20:05 ` Pat Rogers
1994-12-16 1:01 ` Bob Duff
1994-12-12 14:50 ` Garlington KE
1994-12-13 21:48 ` Tucker Taft
1994-12-14 12:44 ` Gentle
1994-12-14 17:34 ` Jean D. Ichbiah
1994-12-10 10:10 ` Marc Wachowitz
1994-12-11 21:37 ` Bob Duff
1994-12-02 23:41 ` Reference Counting (was Re: Searching Method for Incremental Garbage Collection) Bob Duff
1994-12-03 8:16 ` Bill Birch
1994-11-30 18:59 ` Hans Boehm
1994-12-01 3:20 ` R. William Beckwith
1994-12-01 3:51 ` R. William Beckwith
1994-12-01 13:59 ` Henry G. Baker
1994-12-02 4:26 ` R. William Beckwith
1994-12-02 21:37 ` Hans Boehm
1994-12-03 15:17 ` Henry G. Baker
1994-12-09 22:07 ` Bob Duff
1994-12-11 23:59 ` Gary McKee
1994-12-12 5:04 ` Henry G. Baker
1994-12-12 12:46 ` R. William Beckwith
1994-12-16 19:35 ` Bob Duff
1994-12-17 20:36 ` Robert Dewar
1994-12-20 5:24 ` Henry G. Baker
1994-12-12 9:36 ` Robb Nebbe
1994-12-13 16:12 ` Henry G. Baker
[not found] ` <3be0mh$1p7@ga <3bii2g$kn2@news.parc.xerox.com>
1994-12-01 4:58 ` Kevin Warne
1994-12-02 21:58 ` Hans Boehm
[not found] <D06r8x.JBy@inmet.camb.inmet.com>
1994-12-02 17:32 ` Henry G. Baker
1994-12-05 20:59 ` Robert Firth
1994-12-06 14:15 ` Robert Dewar
1994-12-04 1:06 ` Rick Busdiecker
1994-12-04 18:57 ` R. William Beckwith
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox