[gclist] Finalizers & Reference counting.

[Eliot Moss]

>>>>> "Charles" == Charles Fiterman <cef@geodesic.com> 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               moss@cs.umass.edu              email
Amherst, MA  01003-9264  USA              +1-413-545-3733 Priscilla Coe  sec'y
==============================================================================