From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,8e3b3db66f3b0061 X-Google-Attributes: gid109fba,public X-Google-Thread: fd443,8e3b3db66f3b0061 X-Google-Attributes: gidfd443,public X-Google-Thread: 1014db,8e3b3db66f3b0061 X-Google-Attributes: gid1014db,public X-Google-Thread: f4fd2,8e3b3db66f3b0061 X-Google-Attributes: gidf4fd2,public X-Google-Thread: 103376,474d28ddf953b3c1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-29 20:51:53 PST Newsgroups: alt.lang.design,comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.lang.ada Path: bga.com!news.sprintlink.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: 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 Xref: bga.com alt.lang.design:127 comp.lang.c:32498 comp.lang.c++:38848 comp.lang.lisp:4211 comp.lang.ada:8073 Date: 1994-11-30T02:27:57+00:00 List-Id: 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 ^^^ ^^^^