Re: Finalizers & Reference counting.
Eliot Moss <[email protected]>
| Newsgroups | gmane.comp.programming.garbage-collection.general |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "Charles" == Charles Fiterman <[email protected]> writes: Charles> This means collection occurs all at one time. Concurrent Charles> collection generally changes this but there are always special Charles> situations where it doesn't. For example the mutator can go Charles> into a flurry of changes where it touches every page in the Charles> system and keeps the collector from ever finishing. This last statement is one I disagree with. I think you have some particular concurrent collector in mind, but not all concurrent collectors have this behavior. For example, Cheng and Blelloch published an algorithm with proved bounds (I will admit it was for a limited case). Also, Rick Hudson and I have published the Sapphire concurrent algorithm, and I believe it is possible to implement it so that it is guaranteed to terminate, regardless of mutator behavior. As with any concurrent or incremental scheme, you have to devote enough resources to collection so that collection will complete before mutator allocation runs you out of memory, forcing a mutator to block. I have a student doing a new implementation of Sapphire, and he expects to compare it to some other algorithms and better understand their characteristics in practice. Hope this helps some. -- Eliot ============================================================================== J. Eliot B. Moss, Associate Professor http://www.cs.umass.edu/~moss www Director, Arch. and Lang. Impl. Lab. +1-413-545-4206 voice Department of Computer Science +1-413-695-4226 cell 140 Governor's Drive, Room 372 +1-413-545-1249 fax University of Massachusetts [email protected] email Amherst, MA 01003-9264 USA +1-413-545-3733 Priscilla Coe sec'y ==============================================================================