Object resurrection causes a number of problems, particularly that the possibility of object resurrection – even if it does not occur – makes garbage collection significantly more complicated and slower, and is a major reason that finalizers are discouraged.
First, an object becomes garbage when it is no longer reachable from the program, and may be collected (destroyed and deallocated).
If this happens, the referenced object – which is not necessarily the finalized object – is no longer garbage, and cannot be deallocated, as otherwise the references to it would become dangling references and cause errors when used, generally program crash or unpredictable behavior.
Instead, in order to maintain memory safety, the object is returned to life or resurrected.
Resurrects itself by creating a reference in an object it can reach: Resurrects itself by creating a reference in the global environment: In the above examples, in CPython prior to 3.4, these will run finalizers repeatedly, and the objects will not be garbage-collected, while in CPython 3.4 and later, the finalizers will only be called once, and the objects will be garbage-collected the second time they become unreachable.
Starting in Python 3.4, behavior is largely the same as Java:[b] objects are only finalized once (being marked as "already finalized"), garbage collection of cycles is in two phases, with the second phase checking for resurrected objects.
[5][6] Objective-C 2.0 will put resurrected objects into a "zombie" state, where they log all messages sent to them, but do nothing else.
With object resurrection, a pooling technique would reduce the unnecessary overhead of creation and destruction.