Re: A non-sucking garbage collector

Mark Hahn wrote:

> AARRGGHH.  Not only is the idea of an add-on deterministic
> finalization feature unworkable, but I don't see how I can do any
> kind of finalization on a copying collector, deterministic or not.
> The copying collector only visits reachable objects and then leaves
> all others behind as trash.  Since they are never visited they will
> never be called to be finalized.  I don't even think it is possible
> to find those objects since they aren't kept in any kind of linked
> structure.

I panicked a little too soon as usual.  It is possible to find the dead
objects and it isn't clear the extra pass will be a performance problem.
Sorry to drag all of you along my unstable journey through life.

We will be able to make only this one clear statement about the determinism
of our finalization:  "Every non-reachable object will be guaranteed to be
finalized in the next immediate collection pass, even those in reference
cycles".

This is more than you can say for Python objects in a cycle.  We can set a
command-line option for a maximum time between cycles.  This gives a hard
wall-clock time limit on finalization.

We will not be able to add any further improvements to the determinism in
the future.