RFR 9: 8165641 : Deprecate Object.finalize
hboehm at google.com
Tue Mar 14 22:02:48 UTC 2017
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
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.
> 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>
>> > On Mar 14, 2017, at 10:37 AM, Stuart Marks <stuart.marks at oracle.com>
>> > 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
>> > 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
>> I don’t know about this. Certainly it would be something to look into.
>> > 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
>> >> deprecate Object.finalize and the overrides in the JDK to communicate
>> >> 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
>> >> 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
More information about the core-libs-dev