Hi,
A common cleaner was considered but it would be susceptible to one of
the same problems
as finalizers. A bug in the cleanup code could block the thread due to
locks or deadlock,
and hold up cleanup for all of its clients. It would be an attractive
nuisance.
Library or modules can create a cleaner shared and any issues can be
resolved within that context.
Roger
On 3/10/2017 9:15 PM, Hans Boehm wrote:
IIUC, all of the replacements for finalizers (Cleaners,
PhantomReferences) still have the problem that they can't easily share
a single thread across separately-developed libraries to actually run
the cleanups? It seems to me that has been the only even
halfway-convincing reason to still use finalizers for a long time, but
it seems to be a pretty good one in practice.
On Fri, Mar 10, 2017 at 5:36 PM, Kim Barrett <[email protected]
<mailto:[email protected]>> wrote:
> On Mar 10, 2017, at 4:40 PM, Roger Riggs <[email protected]
<mailto:[email protected]>> wrote:
>
> Finalizers are inherently problematic and their use can lead to
performance issues,
> deadlocks, hangs, and other problematic behavior.
>
> The problems have been accumulating for many years and the first
step to
> deprecate Object.finalize and the overrides in the JDK to
communicate the
> issues, recommend alternatives, and motivate changes where
finalization is currently used.
>
> The behavior of finalization nor any uses of finalize are not
modified by this change.
> Most of the changes are to suppress compilation warnings within
the JDK.
>
> Please review and comment.
>
> Webrev:
>
http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/
<http://cr.openjdk.java.net/%7Erriggs/webrev-finalize-deprecate-8165641/>
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8165641
<https://bugs.openjdk.java.net/browse/JDK-8165641>
>
> Thanks, Roger
looks good.
