Talk:Finalizer

Latest comment: 6 years ago by Klbrain in topic Proposed merge with Finalization

Object resurrection problem artificial?

edit

From the current article version:

Languages with finalizers must also address the problem of object resurrection. Resurrection occurs when an object's finalizer causes the object to become reachable (that is, not garbage). The garbage collector must determine if the object has been resurrected by the finalizer or risk creating a dangling reference.

At least from a Java viewpoint, isn't this consideration quite artificial? Can someone come up with an example Object.finalize() implementation that could possibly cause such a problem? I can only see this problem (an object becoming reachable again after exuciting its finalize() method) if the finalize() method called some other object's method passing a this reference. --Abdull (talk) 15:57, 13 April 2012 (UTC)Reply

The object does not became reachable after execution of the finalize method, it is already reachable during execution of the finalize method. For creating a heap reference persisting longer than the method execution, the method has all possibilities Java offers
public class BadFinalize {
  static BadFinalize REFERENCE;
  protected void finalize() throws Throwable {
    REFERENCE = this;
  }
}
But it doesn’t matter whether the finalizer really does this, the VM has to prove safely that it didn’t. At the cost of an extra garbage collection cycle. This is another reason not to use finalizers. — Preceding unsigned comment added by 77.188.68.217 (talk) 14:10, 1 August 2012 (UTC)Reply

Proposed merge with Finalization

edit

Finalization is what a finalizer does. These two articles discuss exactly the same topic. QVVERTYVS (hm?) 09:21, 11 November 2015 (UTC)Reply

Agreed and   Done Klbrain (talk) 09:19, 28 December 2017 (UTC)Reply