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. _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
