finalize() *not* much better than PhantomReferences (Re: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.
Rony G. Flatscher
Rony.Flatscher at wu.ac.at
Thu Aug 5 15:45:37 UTC 2021
Dear Hans, dear Kim,
On 05.08.2021 03:21, Kim Barrett wrote:
>> On Aug 4, 2021, at 9:11 PM, Hans Boehm <hboehm at google.com> wrote:
>> One complication with bare PhantomReferences (as opposed to e.g. Cleaners) is that you need to make sure that the Reference itself is kept reachable, by putting it in some reachable data structure. As the spec says: "If a registered reference becomes unreachable itself, then it will never be enqueued." Normally the ReferenceQueue processing code will need to remove it from that data structure. There's typically a fair amount of boilerplate involved in correct use.
>> I think this can be unexpected for users. Could that be causing the problem here?
> That sounds like a good guess.
thank you very much for this information!
Indeed that was the reason. Adding the PhantomReferences to an IdentityHashMap at creation time
causes them to be placed on the reference queue in a comparable timely manner as compared to the
usage of the finalize() method! (And removing the reference from the IdentityHashMap once it got
removed from the reference queue.)
Going back to the documentation of PhantomReference (Java 6 and 11) this is something I would not
have concluded (but then, I am not a native English speaker). It might help to give a nutshell
example in the documentation that demonstrates how to properly use this important feature or
otherwise stress this important "detail" in the documentation text with a brief sentence!
Sorry therefore to have claimed a false information on the subject line, which I try to make good by
changing it to what the right information is with this message!
Again, thank you very much for pointing this out, you have saved me a lot of time!
More information about the jdk-dev