comp.lang.ada
 help / color / mirror / Atom feed
From: kevinw@whistler.com (Kevin Warne)
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Date: 1 Dec 1994 04:58:44 GMT
Date: 1994-12-01T04:58:44+00:00	[thread overview]
Message-ID: <3bjl64$1q8@scipio.cyberstore.ca> (raw)
In-Reply-To: 3be0mh$1p7@ga <3bii2g$kn2@news.parc.xerox.com

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++



  parent reply	other threads:[~1994-12-01  4:58 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
     [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 [this message]
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