Re: RFR 9: 8165641 : Deprecate Object.finalize

> On 15 Apr 2017, at 08:51, Gil Tene wrote: > A few things are keeping the JDK code from evolving to properly use > Reference.reachabilityFence(this): > > a. It didn't exist until recently. [That's a very good excuse] > > b. While Reference.reachabilityFence exists now, it's

Re: RFR 9: 8165641 : Deprecate Object.finalize

IMO, so long as the JDK's own performance-sensitive methods do not follow this advice, it will be hard to "educate" people to use reachabilityFence responsibly. To be specific: As long as java.nioDirectByteBuffer.get() is effectively coded like this (after the templates are applied):

Re: RFR 9: 8165641 : Deprecate Object.finalize

Thanks Mandy, I'll put you down as a reviewer for the fix. (8165641 was pushed) diff --git a/src/java.base/share/classes/java/lang/Object.java b/src/java.base/share/classes/java/lang/Object.java --- a/src/java.base/share/classes/java/lang/Object.java +++

Re: RFR 9: 8165641 : Deprecate Object.finalize

+1 Mandy > On Apr 6, 2017, at 7:44 AM, Roger Riggs wrote: > > Thanks Mandy, I'll put you down as a reviewer for the fix. (8165641 was > pushed) > > > diff --git a/src/java.base/share/classes/java/lang/Object.java >

Re: RFR 9: 8165641 : Deprecate Object.finalize

(I would not have deprecated finalize; I don't think we have a good enough answer for what to use instead. But) Looks good. Typo: an finalizable object

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Apr 3, 2017, at 7:44 AM, Roger Riggs wrote: > > [1] http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641 Typo: s/an finalizable/a finalizable/ + * The {@code finalize} method might be called on an finalizable object Otherwise, looks good. No

Re: RFR 9: 8165641 : Deprecate Object.finalize

The api note for Object.finalize is not an optimal location for this more general advice, but is good as far as it can go in relation to the current changes to deprecate Object.finalize(). The webrev[1] is updated to add a paragraph to the apiNote[2]: * @apiNote * Classes that embed

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 31/03/17 19:56, Hans Boehm wrote: > This method should be used when cleanup actions (finalize() calls, or > Reference enqueuing, Cleaner invocation) could otherwise be triggered while > a resource under control of the object is still in use. This method should > normally be called when these

Re: RFR 9: 8165641 : Deprecate Object.finalize

Agree entirely with Andrew's concern. I would mostly point to the java.lang.Reference documentation. One possible approach follows. Add the following to the apiNote. I would add it at the beginning, since I've rarely encountered the inheritance issues, and they're probably easier to debug: As

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi Stuart, ok, will switch to @SuppressWarnings; it will avoid the deprecation related clutter in the javadoc. Thanks, Roger On 3/31/2017 1:29 PM, Stuart Marks wrote: On 3/31/17 6:55 AM, Roger Riggs wrote: The webrev for deprecating finalize has been updated: - to improve the advice

Re: RFR 9: 8165641 : Deprecate Object.finalize

There was some observation (in an off-line conversation) that since this is being deprecated it is probably a bit late to start documenting it with lots of advice along these and other lines .. -phil. On 03/31/2017 10:25 AM, Roger Riggs wrote: Hi Hans, Can you suggest how that would be

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 3/31/17 6:55 AM, Roger Riggs wrote: The webrev for deprecating finalize has been updated: - to improve the advice existing JDK subclasses overriding finalize provides in @deprecated javadoc, - to expand Object.finalize() javadoc to reinforce the correct use of super.finalize() by

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi Hans, Can you suggest how that would be expressed? The advice would seem to have some complex conditions. Would it be the case that a caller using a reference to any resource held by a finalizable object must use reachabilityFence to ensure that the resource can not be cleaned up while

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 31/03/17 18:05, Hans Boehm wrote: > Can we add a warning that it is almost never safe to override finalize() > without use of reachabilityFence()? We'll have to be careful not to suggest to some people that if you don't override finalize() then you don't need reachabilityFence(). Careful

Re: RFR 9: 8165641 : Deprecate Object.finalize

The webrev for deprecating finalize has been updated: - to improve the advice existing JDK subclasses overriding finalize provides in @deprecated javadoc, - to expand Object.finalize() javadoc to reinforce the correct use of super.finalize() by subclasses, - and to remove redundant

Re: RFR 9: 8165641 : Deprecate Object.finalize

dhat.com>; Hans Boehm <mailto:hbo...@google.com>; Uwe Schindler <mailto:uschind...@apache.org> *Cc: *core-libs-dev <mailto:core-libs-dev@openjdk.java.net> *Subject: *Re: RFR 9: 8165641 : Deprecate Object.finalize On 15/03/2017 8:21 PM, Timo Kinnunen wrote: Hi, If

RE: RFR 9: 8165641 : Deprecate Object.finalize

, perhaps, but as Java 8 demonstrates it’s a bar that’s attainable. Sent from Mail for Windows 10 From: David Holmes Sent: Wednesday, March 15, 2017 11:38 To: Timo Kinnunen; Andrew Haley; Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 15/03/2017

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 15, 2017, at 11:39 AM, Roger Riggs wrote: > > Hi Mandy, > > I re-checked and @deprecated is not inherited; and if it was it would include > a generic message from the super > so the @deprecated content is needed. Sample of >

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi Mandy, I re-checked and @deprecated is not inherited; and if it was it would include a generic message from the super so the @deprecated content is needed. Sample of javax.imageio.stream.FileImageInputStream.[1] Only minor cleanup to the webrev:

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi, yes, the thread should use try...finally to cleanup its resources explicitly. The method to cleanup and release resources should *not* be called finalize and should be idempotent. Finalization is needed as a last resort it should call the cleanup method (and nothing else). Not all

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 15/03/17 10:21, Timo Kinnunen wrote: > If we are to come up with a good alternative to finalization, having > to compare disparate things seems unavoidable. Comparing threads and > Threads, suppose there’s a subclass of Thread which holds a native > resource that’s not reachable from any other

Re: RFR 9: 8165641 : Deprecate Object.finalize

ail for Windows 10 From: Andrew Haley Sent: Tuesday, March 14, 2017 11:14 To: Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 12/03/17 23:55, Hans Boehm wrote: But I think we agree that it doesn't matt

RE: RFR 9: 8165641 : Deprecate Object.finalize

to replace it. Sent from Mail for Windows 10 From: David Holmes Sent: Wednesday, March 15, 2017 00:57 To: Timo Kinnunen; Andrew Haley; Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 15/03/2017 12:01 AM, Timo Kinnunen wrote: > Hi, > > Fil

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 14/03/17 20:44, Hans Boehm wrote: > It's not hard to add an API to tell the garbage collector to pretend > that you're holding onto those 18GB of additional memory when it > decides whether to collect, without actually actually holding onto > all of that memory. It may not be hard to add the

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 14, 2017, at 7:06 PM, Roger Riggs wrote: > > On 3/14/17 4:53 PM, Mandy Chung wrote: >> This patch looks fine in general. >> >> Does @inheritDoc inherit @deprecated? What does the javadoc of >> javax.imageio.stream.* look like? > Yes, the deprecation is

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi Mandy, Webrev updated in place with your and Stuart's review comments. http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/ On 3/14/17 4:53 PM, Mandy Chung wrote: This patch looks fine in general. Does @inheritDoc inherit @deprecated? What does the javadoc of

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi Stuart, Thanks, I'll remove the unnecessary @SuppressWarnings in the next update. Roger On 3/13/17 6:57 PM, Stuart Marks wrote: As Dr Deprecator, I approve of this change. :-) One small comment. Deprecation warnings aren't issued at the use site of a deprecated API if the use site

Re: RFR 9: 8165641 : Deprecate Object.finalize

Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 12/03/17 23:55, Hans Boehm wrote: But I think we agree that it doesn't matter for this discussion; neither of these problems are addressed by deprecating finalizers. PhantomReferences have exactly the same

Re: RFR 9: 8165641 : Deprecate Object.finalize

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

Re: RFR 9: 8165641 : Deprecate Object.finalize

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

Re: RFR 9: 8165641 : Deprecate Object.finalize

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

Re: RFR 9: 8165641 : Deprecate Object.finalize

This patch looks fine in general. Does @inheritDoc inherit @deprecated? What does the javadoc of javax.imageio.stream.* look like? + * @deprecated Finalization is deprecated and should not be used. + * See {@link Object#finalize} for the explanation and recommended

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 14, 2017, at 10:37 AM, Stuart Marks 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

Re: RFR 9: 8165641 : Deprecate Object.finalize

turns out > you’ll always have that much memory available by definition, so really no > memory would have to be wasted at all. > > > > Sent from Mail for Windows 10 > > From: Andrew Haley > Sent: Tuesday, March 14, 2017 19:03 > To: Timo Kinnunen; Hans Boe

RE: RFR 9: 8165641 : Deprecate Object.finalize

10 From: Andrew Haley Sent: Tuesday, March 14, 2017 19:03 To: Timo Kinnunen; Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 14/03/17 14:01, Timo Kinnunen wrote: > File handles aren’t that scarce of a resource, really, at least on > W

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 14/03/17 14:01, Timo Kinnunen wrote: > File handles aren’t that scarce of a resource, really, at least on > Windows. I've seen processes running out of file handles. It is possible to change the per-process limit. And, of course, there is a lot of hidden context in the kernel and device

Re: RFR 9: 8165641 : Deprecate Object.finalize

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,

RE: RFR 9: 8165641 : Deprecate Object.finalize

handles to use slot-0 of new long[65536]; Sent from Mail for Windows 10 From: Andrew Haley Sent: Tuesday, March 14, 2017 11:14 To: Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize On 12/03/17 23:55, Hans Boehm wrote: > But I think we ag

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 12/03/17 23:55, Hans Boehm wrote: > But I think we agree that it doesn't matter for this discussion; > neither of these problems are addressed by deprecating > finalizers. PhantomReferences have exactly the same issues. And in > my experience it's unfortunately unrealistic to say we're going

Re: RFR 9: 8165641 : Deprecate Object.finalize

As Dr Deprecator, I approve of this change. :-) One small comment. Deprecation warnings aren't issued at the use site of a deprecated API if the use site itself is deprecated. Thus, the @SuppressWarnings annotation isn't necessary in the following diff hunk: ---

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 3/13/17 5:17 AM, Andrew Dinn wrote: On 13/03/17 12:15, Andrew Dinn wrote: On 12/03/17 09:55, Andrew Haley wrote: Oh, absolutely, I know about that. I was just wondering why now, and is this something you just came up with, and are we going to have the compatibility discussion? Perhaps

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 11, 2017, at 1:56 PM, Hans Boehm wrote: > Stepping back, I'm a little surprised at the deprecation. In my opinion, > the problems with finalizers are, in rough order of significance: I think an important difference between finalize and other j.l.r.Reference-based

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi, A reasonably complete treatment of finalizers and suggestions for correct use are in Josh Bloch' Effective Java. It may be a bit dated but is a good start for the casual reader. Josh provided an excerpt: http://www.informit.com/articles/article.aspx?p=1216151=7 There is a lot more to do

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 03/12/2017 07:55 PM, Hans Boehm wrote: But I think we agree that it doesn't matter for this discussion; neither of these problems are addressed by deprecating finalizers. PhantomReferences have exactly the same issues. ... The motivation seems more along the lines of "denigration" vs

Re: RFR 9: 8165641 : Deprecate Object.finalize

In regards to the optimized-out "this" stuff - remember that a while ago Paul Sandoz introduced java.lang.ref.Reference#reachabilityFence()... On 03/12/2017 06:55 PM, Hans Boehm wrote: I agree that's indeed a solvable problem, perhaps not terribly elegantly, but without too much user-visible

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 13/03/17 12:15, Andrew Dinn wrote: > On 12/03/17 09:55, Andrew Haley wrote: >> Oh, absolutely, I know about that. I was just wondering why now, and >> is this something you just came up with, and are we going to have the >> compatibility discussion? > > Perhaps now is the chosen moment (and

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 12/03/17 09:55, Andrew Haley wrote: > Oh, absolutely, I know about that. I was just wondering why now, and > is this something you just came up with, and are we going to have the > compatibility discussion? Perhaps now is the chosen moment (and a good choice at that, I say) because

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 12/03/2017 09:55, Andrew Haley wrote: : I have no problem with the deprecation, BTW. It's what happens next that is more problematic. I think it has to be baby steps and I would expect going further will involve years and several major releases. That should give time to look at use-cases

RE: RFR 9: 8165641 : Deprecate Object.finalize

Hi, > >> I guess "difficulty in properly triggering GC for non-memory resource > >> exhaustion" is closest to what I just described. > > > > This has long been an issue in the Java client area where native desktop > > resources or the like need to be managed carefully, but it is not just > >

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 12/03/17 16:40, Philip Race wrote: > > On 3/12/17, 3:07 AM, Andrew Haley wrote: >> I guess "difficulty in properly triggering GC for non-memory resource >> exhaustion" is closest to what I just described. > > This has long been an issue in the Java client area where native desktop > resources

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 3/12/17, 3:07 AM, Andrew Haley wrote: I guess "difficulty in properly triggering GC for non-memory resource exhaustion" is closest to what I just described. This has long been an issue in the Java client area where native desktop resources or the like need to be managed carefully, but it

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 11/03/17 18:56, Hans Boehm wrote: > > Stepping back, I'm a little surprised at the deprecation. In my opinion, > the problems with finalizers are, in rough order of significance: I would have thought the most significant problem with finalizers is that finalizers may never run unless the

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 11/03/17 11:08, Alan Bateman wrote: > On 11/03/2017 07:59, Andrew Haley wrote: > >> : >> Wow. I totally agree with the sentiment, but it's a bit late in the >> JDK 9 timeframe to be talking about this. Has this been discussed >> internally within Oracle for some time? > For years, long

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi, A common cleaner was considered but it would be susceptible to one of the same problems as finalizers. A bug in the cleanup code could block the thread due to locks or deadlock, and hold up cleanup for all of its clients. It would be an attractive nuisance. Library or modules can create

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 11/03/2017 07:59, Andrew Haley wrote: : Wow. I totally agree with the sentiment, but it's a bit late in the JDK 9 timeframe to be talking about this. Has this been discussed internally within Oracle for some time? For years, long before SUNW was finalized :-) Note that Roger's patch

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 10/03/17 21:40, Roger Riggs wrote: > Finalizers are inherently problematic and their use can lead to > performance issues, > deadlocks, hangs, and other problematic behavior. Wow. I totally agree with the sentiment, but it's a bit late in the JDK 9 timeframe to be talking about this. Has

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 10, 2017, at 4: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 >

RFR 9: 8165641 : Deprecate Object.finalize

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,