RFR 9: 8165641 : Deprecate Object.finalize

[Hans Boehm]

How does that scale to independently developed libraries?

In my world, finalizer deadlocks are relatively easy to diagnose, and a
relatively minor annoyance.

Stepping back, I'm a little surprised at the deprecation. In my opinion,
the problems with finalizers are, in rough order of significance:

1) Premature finalization issues in the absence of reachabilityFence. And I
would be pleasantly surprised if reachabilityFence saw much use.

2) Lack of ordering guarantees.

3) Some less significant issues, like runFinalization() synchronization,
difficulty in properly triggering GC for non-memory resource exhaustion,
slow and deadlocked finalizers, inability to finalize more than once,
potential need for finalizer guardians, etc.

The first two appear on top since they can cause memory corruption in a
world with JNI.

The problems with PhantomReference or Cleaner appear to be:

1) Premature cleanup issues in the absence of reachabilityFence.

2) Too many cleanup threads in large multi-author systems. (Can't cause
memory corruption, but seems to be a serious issue for complex systems
running on resource-constrained hardware.)

3) A similar, though perhaps slightly shorter list of less significant
issues. At least it seems shorter at the moment; most real experience in my
world still seems to be with finalizers. Some of the old problems, like
runFinalization() seem to get worse with the number of clients, since each
client needs to invent its own mechanism.

Although I agree we'd be marginally better off without finalizers, it's
unclear to me the improvement is substantial enough to bother without more
of a replacement story.

On Sat, Mar 11, 2017 at 9:24 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> 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 <kim.barrett at oracle.com>
> wrote:
>
>> > On Mar 10, 2017, at 4:40 PM, Roger Riggs <roger.riggs at oracle.com>
>> 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/
>> >
>> > Issue:
>> >   https://bugs.openjdk.java.net/browse/JDK-8165641
>> >
>> > Thanks, Roger
>>
>> looks good.
>>
>>
>>
>
>