[Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

[Stefan Richthofer]

>You mean Jython deletes instance attributes before calling __del__ ?

No. I think the term of "object resurrection" usually does not mean bringing
back a deleted object in the sense that memory was already freed.
I think it rather means that nothing referred to an object, so it was on the
"kill-list" of gc or zero-ref-count macro.
During its finalizer call, the object managed to get some reference
again. GC or zero-ref-count macro checks refcount again after the
finalizer call (doesn't it?) and then refrains from the originally triggered
deletion-task.

Where things get weired is how to treat objects (e.g. x2) that are
reachable via the original
object (e.g. x) only.

x becomes unreachable => x2 is unreachable too

CPython behavior:
free x's weakrefs, call x.__del__ => x2 is reachable again => free
memory of x; don't touch x2 at all

Java/Jython behavior:
free all weakrefs, call all finalizers of unreachable objects, i.e. call
x.__del__, call x2.__del__ (and maybe more)
=> x2 is reachable again => free memory of x; let x2 survive
(x2 even survives at least for another gc-cycle if the finalizer of x or
x2 only created a weak ref)

At least in Java/Jython case I would call x2 to be "resurrected", i.e.
its finalizer was called and weakrefs were cleared. It was on the
death-list and escaped from it. This finally brings the definition of
the word "resurrection" to its limit in language independent sense as
one can argue there was no resurrection of x2 in CPython although it's
one and the same scenario.

>In which use case exactly?
The one with "indirect resurrection".
Would it have CPython behavior as sketched above or Java/Jython
behavior? (I confirmed the sketched behavior only for ref-drop-to-zero
triggered cleanup)


Best,

Stefan


On 10/27/2014 04:31 PM, Antoine Pitrou wrote:
> On Mon, 27 Oct 2014 16:20:06 +0100
> Stefan Richthofer <stefan.richthofer at gmx.de> wrote:
>> I already pointed out
>> "One can surely argue x2 has never been dead, or see it as
>> "it was killed along with x and then resurrected by x"."
>>
>> In Java and thus in Jython, it is treated as the second one.
> You mean Jython deletes instance attributes before calling __del__ ?
> That would make most __del__ implementations quite useless...
> And actually your own example would fail with an AttributeError on
> "X.y = self.z".
>
>> What would still be interesting (at least when Jython 3 is born),
>> is which of the mentioned behaviors occurs if it is
>> performed by CPython's cyclic gc (consistently the first one I would guess).
> In which use case exactly? :-) I've lost track a bit, since you've
> posted several examples...
>
> Regards
>
> Antoine.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.de