RFR 9: 8165641 : Deprecate Object.finalize

[Mandy Chung]

On Mar 14, 2017, at 3:02 PM, Hans Boehm <hboehm at google.com> wrote:
> 
> 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.
> 

Block indefinitely in the current implementation.  No time out.

Do you mind filing a JBS issue for such a warning?

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

Hmm… I have to check it.

Mandy

> On Tue, Mar 14, 2017 at 2:54 PM, Mandy Chung <mandy.chung at oracle.com <mailto: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 <mailto: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 <mailto:mandy.chung at oracle.com>> wrote:
>> > On Mar 14, 2017, at 10:37 AM, Stuart Marks <stuart.marks at oracle.com <mailto: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/ <http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/>
>> >>
>> >> Issue:
>> >>   https://bugs.openjdk.java.net/browse/JDK-8165641 <https://bugs.openjdk.java.net/browse/JDK-8165641>
>> >>
>> >> Thanks, Roger
>> >>
>> >>
>> 
>> 
> 
>