RFR 9: 8165641 : Deprecate Object.finalize

[Bernd Eckenfels]

The problem with runFinalizers() is that it only executes one additional (second) finalized-queue processing thread.

It will not trigger the Gc mechanism needed to actually detect and enqueue the unreachable candidates. So it might help with slow or stalled finalize() calls, but by doing so it may block or take long to terminate itself (the invocation joins the system thread). I think that's JEP132 related.

Gruss
Bernd

BTW: For me having a guarantee max-Intervall for tenured generation reference processing (trigger a mixed collection) is something which could improve the robustness in face of oversized old generations. Especially when off heap resources wait for it.

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Hans Boehm <hboehm at google.com>
Sent: Tuesday, March 14, 2017 10:02:01 PM
To: Mandy Chung
Cc: core-libs-dev
Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize

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
> >>
> >>
>
>