Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection
You mean Jython deletes instance attributes before calling __del__ ?
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
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. 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@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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.d...
On Mon, 27 Oct 2014 17:23:23 +0100 Stefan Richthofer <stefan.richthofer@gmx.de> wrote:
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.
"x2" does *not* have its refcount drop to zero, since it is still referenced by x. In other words, "x2" can only be on a "kill list" after "x" has been finalized, which can only be *after* __del__ was executed. If Jython does things differently, then certainly its behaviour is incompatible with the common expectations of Python developers. Regards Antoine.
I already admitted that it is implementation specific whether one would talk of resurrection, even in one and the same scenario. (Although I would prefer to agree on an abstract notion of the resurrection term.)
If Jython does things differently, then certainly its behaviour is incompatible with the common expectations of Python developers.
Guido recently pointed out that it is allowed for different Python implementations to alter details of gc behavior. (And I suppose this was more a reminder of already common consensus.) However I agree that some aspects could be improved and I am looking at it. So far I have all answers I needed. Thanks for the discussion! -Stefan On 10/27/2014 05:36 PM, Antoine Pitrou wrote:
On Mon, 27 Oct 2014 17:23:23 +0100 Stefan Richthofer <stefan.richthofer@gmx.de> wrote:
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. "x2" does *not* have its refcount drop to zero, since it is still referenced by x. In other words, "x2" can only be on a "kill list" after "x" has been finalized, which can only be *after* __del__ was executed.
If Jython does things differently, then certainly its behaviour is incompatible with the common expectations of Python developers.
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.d...
On Mon, 27 Oct 2014 18:40:24 +0100 Stefan Richthofer <stefan.richthofer@gmx.de> wrote:
If Jython does things differently, then certainly its behaviour is incompatible with the common expectations of Python developers.
Guido recently pointed out that it is allowed for different Python implementations to alter details of gc behavior.
I'm afraid you misunderstood this whole sub-branch of the discussion. Regards Antoine.
On 10/27/2014 12:23 PM, Stefan Richthofer wrote:
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.
In either case, there is a final reference keeping the object alive, like an hospital patient kept alive by a final link with a life-support machine. I think 'resuscitation' might be a better metaphor. -- Terry Jan Reedy
I think 'resuscitation' might be a better metaphor.
The term 'resurrection' is not my invention, but well established: http://en.wikipedia.org/wiki/Object_resurrection I well understand why Antoine objects to calling it "resurrection" in CPython due to implementation specific reasons. But in the above article (which I consider rather detailed) I can't find anything stating that an object's ref-count must drop to zero at any time in order to call it "resurrected". In contrast, it clarifies that objects can not only resurrect themselves: "...which may in turn make that object or another garbage object (reachable from the object with a finalizer) reachable again" "If this happens, the referenced object – which is not necessarily the finalized object – is no longer garbage, and cannot be deallocated"
"x2" does *not* have its refcount drop to zero, since it is still referenced by x. In other words, "x2" can only be on a "kill list" after "x" has been finalized, which can only be *after* __del__ was executed.
x resurrects x2 in the sense that it must "actively" have an action in its finalizer that establishes a new reference to x2 in non-garbage or environment memory. Otherwise x as the "final life support link" of x2 would cause x2's ref count *actually* drop to zero in the next step. I never wanted this to become a discussion about the definition of object resurrection. I just wanted to understand which details in different behavior (such as weakref breaking) are okay and which are bugs (as breaking consistency of id() in Jython). Regards -Stefan
Gesendet: Montag, 27. Oktober 2014 um 23:36 Uhr Von: "Terry Reedy" <tjreedy@udel.edu> An: python-dev@python.org Betreff: Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection
On 10/27/2014 12:23 PM, Stefan Richthofer wrote:
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.
In either case, there is a final reference keeping the object alive, like an hospital patient kept alive by a final link with a life-support machine. I think 'resuscitation' might be a better metaphor.
-- Terry Jan Reedy
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.d...
participants (4)
-
Antoine Pitrou -
Stefan Richthofer -
Stefan Richthofer
-
Terry Reedy