<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body style="background-color: rgb(255, 255, 255); color: rgb(0, 0,
    0);" bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 06/08/2015 09:47 PM, Kim Barrett
      wrote:<br>
    </div>
    <blockquote
      cite="mid:6028BE66-BE55-4C51-96C0-63252C9D1D00@oracle.com"
      type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
      <pre wrap="">On Jun 6, 2015, at 11:02 AM, Peter Levart <a class="moz-txt-link-rfc2396E" href="mailto:peter.levart@gmail.com"><peter.levart@gmail.com></a> wrote:
</pre>
      <blockquote type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
        <pre wrap="">I understand that it would be desirable for a finalizable object to be made "untracked" as soon as it is manually cleaned-up. This would most certainly give a relief to GC as it could reclaim such untracked objects immediately like normal objects without pushing them through all the finalization steps.

Such feature would need new API. Here's my take on such API incorporated in my prototype. This feature is mostly independent of other changes in the prototype and could be provided stand-alone. I choose to incorporate it into the prototype to compare it's overhead with classical finalization in unchanged and changed JDKs:

    <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.03/">http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.03/</a>
</pre>
        <!--[if !IE]></DIV><![endif]--></blockquote>
      <pre wrap="">While changes are needed to do this sort of thing, it seems to me a better change would be to not use finalize() at all, </pre>
      <!--[if !IE]></DIV><![endif]--></blockquote>
    <br>
    You mean FinalReference, right? This is the only remaining Reference
    type that isn't cleared automatically by GC. So if a XxxReference is
    cleared when it is discovered with referent being xxx-ly-reachable
    and later enqueued by ReferenceHandler thread, then GC has less work
    with it? Why is automatically cleared Reference more lightweight
    than FinalReference? Because GC can reclaim such referent right away
    in the same GC cycle as hooking it on the pending list?<br>
    <br>
    <blockquote
      cite="mid:6028BE66-BE55-4C51-96C0-63252C9D1D00@oracle.com"
      type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
      <pre wrap="">but instead use PhantomReference-based cleanup. It provides exactly that kind of behavior, and has other benefits besides.

There is some discussion about doing exactly that for File{Input,Output}Stream (see <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8080225">https://bugs.openjdk.java.net/browse/JDK-8080225</a>).

</pre>
      <!--[if !IE]></DIV><![endif]--></blockquote>
    <br>
    sun.misc.Cleaner is already such thing (a PhantomReference). Would
    it be of interest to have a public API similar to sun.misc.Cleaner,
    but with the following difference:<br>
    <br>
    - public "Cleaners" would be executed by same thread(s) as
    finalize() methods. This would detach their execution from
    ReferenceHandler thread which must dispatch all references and must
    not be disturbed by user code.<br>
    <br>
    Regards, Peter<br>
    <br>
  </body>
</html>