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,start X-Google-Attributes: gid103376,public X-Google-Thread: fd443,8e3b3db66f3b0061 X-Google-Attributes: gidfd443,public X-Google-ArrivalTime: 1994-11-29 18:50:32 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!rutgers!goclenius.rutgers.edu!dziuxsolim.rutgers.edu!uunet!ankh.iia.org!ralph.vnet.net!news1.digex.net!ois.com!ois.com!not-for-mail From: beckwb@ois.com (R. William Beckwith) Newsgroups: alt.lang.design,comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.lang.ada Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection) Followup-To: alt.lang.design,comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.lang.ada Date: 29 Nov 1994 16:27:46 -0500 Organization: Objective Interface Systems, Inc. Message-ID: <3bg6ci$18k@gamma.ois.com> References: <3be0mh$1p7@gamma.ois.com> <3bfprn$okr@scipio.cyberstore.ca> NNTP-Posting-Host: gamma.ois.com X-Newsreader: TIN [version 1.2 PL2] Xref: bga.com alt.lang.design:125 comp.lang.c:32473 comp.lang.c++:38825 comp.lang.lisp:4208 comp.lang.ada:8070 Date: 1994-11-29T16:27:46-05:00 List-Id: Kevin Warne (kevinw@whistler.com) wrote: : Depending on the number of inc/decs, the cost of RCing can be very : significant. A single inc + dec that hits on-chip cache would : take 6 cycles. Multiply by the avg. number of inc/decs taken : per object and the cost and percentage of cache misses and I think : you'll find the incrementing and decrementing operations are : consequential after all. 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. Paul Wilson's RT, generational, incremental GC'tor causes work when the graph of objects is changed (write barrier). Surely, the color changes required with a graph change can be as fast as a simple incr/decr operation. Maybe my perspective is skewed because I have been RC'ing in Ada 9X. I realize that C++ calls a copy constructor if you pass an object as an argument by value. But I was under the assumption that every C++ RC'ing implementation worth its salt would require that the reference objects are passed by reference (&). The other trick about RC'ing is that you don't have to keep the counts in the objects, you can keep them all in the same data structure so that you pages are unnecessarily dirtied. ... Bill ------------------------------------------------------ e-mail: Bill.Beckwith@ois.com | Team Ada Objective Interface Systems, Inc. | dist, full O-O 1895 Preston White Drive, Suite 250 | multithreading Reston, VA 22091-5448 U.S.A. | built in