Re: Finalizers & Reference counting.

But in a real sense, if the mutator keeps making work for the collector, the
collector never finishes.

What's needed is an upper bound on how far the collector can get behind, not
a "finishing" requirement. I believe there are and have been for some time a
number of algorithms which guarentee this. You can guarentee it by simply
blocking the mutator and/or allocator by increasing amounts to let the
collector catch up -- but then you'll also want to establish bounds on how
much delay has to be introduced into those processes (and you'll also be
concerned with overhead, not just theoretical limits).

You might also choose not to call these "concurrant" -- but I think of it
more as managing your resources by dynamically allocating more processors to
the collection process. Much as you state below. Really, I think anything
that incorporates feedback driven by how far behind the collector is or how
low memory is, will serve to drive the collection ahead of the mutator. If
you have one cell free, the mutator only gets to mutate once, while
in-between, the collector processors (i.e. ALL of them) find the one
available cell for the next brief mutation...

Obviously not a viable solution, but a useful thought experiment that
indicates it is *possible* to manage things so the mutator cannot overrun
the collector.

-----Original Message-----
From: Eliot Moss [mailto:[email protected]] 
Sent: Wednesday, August 28, 2002 8:26 AM
Subject: Re: [gclist] Finalizers & Reference counting.


>>>>> "Charles" == Charles Fiterman <[email protected]> writes:

    Charles> ...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. ...

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