RFR 9: 8165641 : Deprecate Object.finalize

[Hans Boehm]

If runFinalization() waits unconditionally for the other thread to
complete, then I think it would be great to add a warning. Conversely, if
it times out quickly enough to consider it non-blocking, that's useful
information, too.

The fact that finalizers run in a new thread is also important, but I think
already follows from JLS 12.6.

On Tue, Mar 14, 2017 at 2:54 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> Since nothing is proposed to be removed in this patch, Object.finalize and
> runFinalization will stay.
>
> runFinalization is a hint.  The spec states that it suggests the JVM
> expend effort toward running the finalizer methods of objects pending for
> finalization.   It’s best effort and no guarantee.   The current
> implementation of runFinalization invokes the finalizers in a new thread so
> that it provides some kind of insulation but it would still be prone to
> deadlock.  We could add a note about such warning.
>
> Mandy
>
>
> On Mar 14, 2017, at 2:02 PM, Hans Boehm <hboehm at google.com> wrote:
>
> If we're going to keep runFinalization(), could we please document clearly
> whether it may block indefinitely or not? It seems to me that the answer to
> this question fundamentally determines the usage model. If not, I can call
> runFinalization() (and possibly gc()) from a library when I'm out of
> resources managed by finalizers. But runFinalization() is really only a
> hint that needs to be careful about blocking. If yes, then
> runFinalization() is likely to deadlock if I call it from any setting in
> which I hold a lock, and this kind of usage is unsafe, unless I run it in a
> separate thread, and refuse to wait for it indefinitely. I can't decide
> whether the current javadoc says "yes" or "no", making any usage suspect.
> "No" is probably a more useful answer, but any clear answer seems like it
> would be a major improvement.
>
> On Tue, Mar 14, 2017 at 1:13 PM, Mandy Chung <mandy.chung at oracle.com>
> wrote:
>
>> > On Mar 14, 2017, at 10:37 AM, Stuart Marks <stuart.marks at oracle.com>
>> wrote:
>> >
>> > Tagir Valeev asked on Twitter whether System.runFinalization() and
>> Runtime.runFinalization() should also be deprecated. The obvious answer is
>> "yes" since we're deprecating finalization, but maybe it's not so obvious.
>> >
>> > One view is that we're not deprecating the entire finalization
>> mechanism, we're simply deprecating Object.finalize() and its overrides.
>> The point of doing this is to encourage code to migrate away from these
>> methods. Code that calls runFinalization() can't rely on it having many
>> semantics, so such calls are harmless. (Well, mostly harmless.) Encouraging
>> migration away from runFinalization() thus isn't necessary.
>> >
>>
>> I agree deprecating runFinalization() isn’t necessary in this proposed
>> patch.  Deprecating Object.finalize would encourage existing code to
>> migrate away from finalizers as well as discourage new code to add any new
>> finalizer.
>>
>> > Another point is that "finalization" in a generic sense can be applied
>> to reference processing, not just calls to the finalize() method.
>>
>> Hmm..  I am not sure what this exactly means here.  But there would be
>> lot to figure out what happens next and what baby steps to take.
>>
>> > Offhand I'm not sure what runFinalization() does today, but perhaps in
>> the future it could be modified to have stronger semantics regarding
>> reference processing -- which is one of the big unresolved issues in this
>> area.
>> >
>>
>> I don’t know about this.  Certainly it would be something to look into.
>>
>> Mandy
>>
>> > What do you think?
>> >
>> > s'marks
>> >
>> > On 3/10/17 1:40 PM, Roger Riggs 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
>> >>
>> >>
>>
>>
>
>