[pypy-dev] The fate of gc-del

Armin Rigo arigo at tunes.org
Mon Aug 12 09:38:23 CEST 2013


Re-hi,

Update after discussion on IRC (thanks cfbolz).

First, there are two problems that should be separated.  One is the
change in interface for RPython programs, calling
rgc.register_finalizer() instead of having regular __del__()s.  The
other is making these finalizers be called more quickly in case of a
chain of objects that all have finalizers.

Let's focus on the second problem.  We found a more reasonable way to
address it --- or at least, to reduce its bad effects to a large
extent.  Recall that finalizers are only run after major collections.
Why?  Because there would be little point in running them after minor
collections.  Consider the case of two objects A -> B, both with
finalizers.  Even if we would discover during a minor collection that
they are dead, they still need to be both promoted to old objects,
after which we can call A.__del__ --- but not B.__del__.  The latter
needs to wait until the following collection --- the following *major*
collection, because at this point B is an old object.

The proposed fix is to re-make these objects young.  In other words,
when we find that A and B are not reachable, all objects that are
referenced only from A or B still survive of course, but they all
become young again.  Then the next *minor* collection will deal with
them again.  In details:

* we run a major or minor collection and find that A -> B are not reachable
* A and B and objects only reachable from them are made young again
* we immediately schedule A.__del__ to be called
* at the next *minor* collection we're again likely to find that B is
not reachable
* B and objects only reachable from it are made young again
* we schedule B.__del__ to be called

...and so on if we have a full chain of objects with finalizers rather
than just two.  They would be finalized at the rythm of one per minor
collection.  Even if not perfect, this is much, much better than the
current rythm, which is one per major collection.

The advantage of this approach is that it's done without RPython
changes, just by tweaks in the GC.


A bientôt,

Armin.


More information about the pypy-dev mailing list