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: f4fd2,8e3b3db66f3b0061 X-Google-Attributes: gidf4fd2,public X-Google-Thread: 1014db,8e3b3db66f3b0061 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,8e3b3db66f3b0061 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,474d28ddf953b3c1 X-Google-Attributes: gid103376,public X-Google-Thread: fd443,8e3b3db66f3b0061 X-Google-Attributes: gidfd443,public X-Google-ArrivalTime: 1994-12-03 07:54:42 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: <3bii2g$kn2@news.parc.xerox.com> <3bjfep$9ss@gamma.ois.com> <3bo43b$61v@news.parc.xerox.com> Date: Sat, 3 Dec 1994 15:17:02 GMT Xref: bga.com alt.lang.design:158 comp.lang.c:33196 comp.lang.c++:39416 comp.lang.lisp:4260 comp.lang.ada:8231 Date: 1994-12-03T15:17:02+00:00 List-Id: In article <3bo43b$61v@news.parc.xerox.com> boehm@parc.xerox.com (Hans Boehm) writes: >beckwb@ois.com (R. William Beckwith) writes: >>You and Henry (et al) are the wizzards here. Do the stack based >>references really cause most of the incr/decr operations? References from the registers and the stack are the most volatile, and therefore cause the most updating of reference counts. This is by definition, since it is impossible to change a reference count in any other way. >Maintaining an explicit list of stack resident roots is >expensive. I would guess that most such schemes are comparable to >reference counting. One alternative is to conservatively >scan the stack. The GC for my Ada83 Lisp implementation maintains an explicit list of stack resident roots using a 'limited private' type. See my ftp/www page for how to get the Ada Letters paper which describes the stack roots scheme. ----- I just wanted to point out again that objects whose reference counts are always one, and the programmer/compiler knows this, avoid the usual overheads of reference counting. For example, one cannot have contention on such objects, and therefore locking isn't necessary, and one need never _check_ the count on such an object when recycling, since one already knows that it is =1, and therefore the object can always be recycled immediately. Such objects are called 'linear', and there are several papers in my ftp/www directory that discuss them. 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 ^^^ ^^^^ (It _is_ accessible, but Netcom is loaded; keep trying.)