On Mar 14, 2017, at 3:02 PM, Hans Boehm <hbo...@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.ch...@oracle.com > <mailto:mandy.ch...@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 <hbo...@google.com >> <mailto:hbo...@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.ch...@oracle.com >> <mailto:mandy.ch...@oracle.com>> wrote: >> > On Mar 14, 2017, at 10:37 AM, Stuart Marks <stuart.ma...@oracle.com >> > <mailto:stuart.ma...@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 >> >> >> >> >> >> > >
