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.6 required=5.0 tests=BAYES_05,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: 109fba,8e3b3db66f3b0061 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,474d28ddf953b3c1 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,8e3b3db66f3b0061 X-Google-Attributes: gid1014db,public X-Google-Thread: fd443,8e3b3db66f3b0061 X-Google-Attributes: gidfd443,public X-Google-ArrivalTime: 1994-11-30 21:17:53 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!unixg.ubc.ca!vanbc.wimsey.com!scipio.cyberstore.ca!usenet From: kevinw@whistler.com (Kevin Warne) 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) Date: 1 Dec 1994 04:58:44 GMT Organization: Cyberstore Systems Message-ID: <3bjl64$1q8@scipio.cyberstore.ca> References: <3be0mh$1p7@ga <3bii2g$kn2@news.parc.xerox.com> NNTP-Posting-Host: 198.70.155.3 X-Newsreader: WinVN 0.92.5 Xref: bga.com alt.lang.design:140 comp.lang.c:32732 comp.lang.c++:39077 comp.lang.lisp:4231 comp.lang.ada:8130 Date: 1994-12-01T04:58:44+00:00 List-Id: In article <3bii2g$kn2@news.parc.xerox.com>, boehm@parc.xerox.com (Hans Boehm) says: >beckwb@ois.com (R. William Beckwith) writes: >>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. > >You do need at least a write barrier on the heap for incremental collection. >(In the best case, the dirty bits in the MMU are a sufficient >write barrier, though not for that algorithm. But using them is likely Can you think of a realistic incremental collection algorithm that uses MMU dirty bits? At best I suppose a collector could perform a collection and then freeze the application while it rescanned pointers in areas covered by dirty bits. >to increase collector latency, though probably not above the simple RC scheme. >And your machine may not have hardware dirty bits, though the Intel >architecture does. And your OS may already need those bits for other >things, adding a bit of overhead.) And don't forget all those OSs who keep the dirty bits to themselves. Just imagine the hell involved to access those bits under the likes of Windows NT and OS/2 (and other operating systems). Still, it would turn card-marking into a win, wouldn't it... >The crucial issue in my mind is whether you can safely avoid counting >pointers from the stack. Any incremental collector (RC or tracing) is going to need a stack barrier unless either A) stacks are scanned atomically at the end of a collection period along with the objects that they reference or B) stack objects have restrictions during collection about what kind of heap objects they may point to. Otherwise stack-based references can circumvent heap barriers. Kevin ____ Kevin Warne / kevinw@whistler.com / DDD +1 604 932 0606 / FAX +1 604 598 9546 Suite 204, 1200 Alpha Lake Road, Whistler, BC, CANADA V0N 1B0 Warne's Garbage Collector (WGC) = The best way to allocate memory in C++