Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

fyi, I filed a separate bug[1] to add the reachabilityFence calls when they reach jdk-dev. Roger [1] https://bugs.openjdk.java.net/browse/JDK-8145459 On 12/17/2015 7:53 AM, Paul Sandoz wrote: On 17 Dec 2015, at 13:07, Peter Levart wrote: I see no other issues left

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On 17 Dec 2015, at 13:07, Peter Levart wrote: > > I see no other issues left besides the reachability races that I talked about > in previous messages. Do you know if Reference.reachabilityFence is being > pushed before this API? > It’s already pushed to hs-comp. I

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, On 12/16/2015 08:47 PM, Roger Riggs wrote: Hi Peter, It was a bit more involved than I expected, mostly in the tests to make this change. Is this what you expected? (just the deltas, I'll merge the patches before pushing).

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

The change > On Dec 16, 2015, at 11:47 AM, Roger Riggs wrote: > > Hi Peter, > > It was a bit more involved than I expected, mostly in the tests to make this > change. > > Is this what you expected? (just the deltas, I'll merge the patches before > pushing). > >

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mandy, On 12/16/2015 3:07 PM, Mandy Chung wrote: The change On Dec 16, 2015, at 11:47 AM, Roger Riggs wrote: Hi Peter, It was a bit more involved than I expected, mostly in the tests to make this change. Is this what you expected? (just the deltas, I'll merge

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Dec 16, 2015, at 12:42 PM, Roger Riggs wrote: > Nit: There is no return value and this @return is not needed. >> * @return does not return >> > right I’m seeing this in other places. You can take them out before you push (no new webrev needed). >> >> In the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, It was a bit more involved than I expected, mostly in the tests to make this change. Is this what you expected? (just the deltas, I'll merge the patches before pushing). http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696-no-clear/ Thanks, Roger On 12/15/2015 6:01 PM,

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

No, you didn't miss any. I didn't know you were using line breaks for readability or meant a new paragraph. No worries. You are right they don't break the paragraph in javadoc. Cheers, Paul On Tue, Dec 15, 2015 at 10:00 AM, Roger Riggs wrote: > Hi Paul, > > The

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Paul, The credit/blame for the Cleaner doc is mine. On 12/15/2015 10:25 AM, Paul Benedict wrote: David, this needs editing. * The cleaning function is invoked after the object it is cleaning up after it * becomes phantom reachable, so it is important that the references and values * it

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, Just one thing about implementation: Since the type exposed to user is Cleaner.Cleanable that has only a single method clean(), it would be good if the implementation class (CleanerImpl.PhantomCleanableRef) overrode CleanerImpl.PhantomCleanable.clear() method and threw

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, That will break up clearing the ref when the Cleanable is explicitly cleaned. Reference.clear() needs to be called from Cleanable.clean(). it might be nice to block that but to do so we'd need to go back to separate objects for the Reference and the Cleanable and we worked hard to

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi David, Thanks for the comments and suggestions from recent emails, they have been applied to the webrev and javadoc. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Roger On 12/15/2015 1:59 AM, David Holmes wrote:

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

David, this needs editing. * The cleaning function is invoked after the object it is cleaning up after it * becomes phantom reachable, so it is important that the references and values * it needs do not prevent the object from becoming phantom reachable. 1) The "after it" looks like a leftover

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Dec 14, 2015, at 2:38 PM, Roger Riggs wrote: > > Hi, > > The complexity of using Lambda for cleaning functions are too hard to explain > in depth > in the context of an example. A more conservative approach is to show using > a static nested class. A lambda

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, On 15/12/2015 8:38 AM, Roger Riggs wrote: Hi, The complexity of using Lambda for cleaning functions are too hard to explain in depth in the context of an example. A more conservative approach is to show using a static nested class. A lambda savvy developer can correctly determine

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 15/12/2015 10:48 AM, Mandy Chung wrote: On Dec 14, 2015, at 2:38 PM, Roger Riggs wrote: Hi, The complexity of using Lambda for cleaning functions are too hard to explain in depth in the context of an example. A more conservative approach is to show using a

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

PS. create(): can also throw SecurityException if not allowed to create/start threads. David On 10/12/2015 4:40 AM, Roger Riggs wrote: Hi, The example is revised to caution about inner classes and lambdas. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, The complexity of using Lambda for cleaning functions are too hard to explain in depth in the context of an example. A more conservative approach is to show using a static nested class. A lambda savvy developer can correctly determine how to avoid the pitfalls, and others should stick

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 14, 2015, at 5:38 PM, Roger Riggs wrote: > > Hi, > > The complexity of using Lambda for cleaning functions are too hard to explain > in depth > in the context of an example. A more conservative approach is to show using > a static nested > class. A lambda

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/09/2015 08:54 AM, David Holmes wrote: On 9/12/2015 5:05 PM, Peter Levart wrote: Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. Problem is that many people - myself included - would not have a clue when

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

At the risk of going off topic with respect to this thread, I really think java should allow specifying at least what should be captured explicitly (if unspecified, behaves like today). It's counterintuitive that capturing just a field of 'this' captures the entire object, although some other

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Peter, On 09/12/15 07:05, Peter Levart wrote: Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. public static class CleanerExample implements AutoCloseable { private static final Cleaner cleaner = ...;

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Chris, On 12/09/2015 04:03 PM, Chris Hegarty wrote: Peter, On 09/12/15 07:05, Peter Levart wrote: Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. public static class CleanerExample implements AutoCloseable

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, The example is revised to caution about inner classes and lambdas. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Thanks, Roger On 12/9/2015 11:04 AM, Peter Levart wrote: Hi Chris, On 12/09/2015 04:03 PM, Chris

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Actually I'm having more doubts about this API. Library writers use finalize() as a last ditch cleanup mechanism in case the user doesn't explicitly call any "cleanup" method. So as a library writer I would think I am now expected to register my instances with a Cleaner and provide a Runnable

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, Sorry I had no choice but to look at this more closely ... and apologies as this is very late feedback ... I only looked at the API not the details of the implementation. On 8/12/2015 4:50 AM, Roger Riggs wrote: Hi David, Thanks for the comments, Updated the javadoc and webrev

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you can (and should, I guess) just use finalize. IMO Cleaners are better when you do not want the instance of an object to be accessible at all before you clean

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

But thinking more on this approach this is simply not scalable. A Cleaner per cleanable-class could result in hundreds of threads being active! And this certainly does not seem easier to use than finalization. What exactly are the advantages over finalization again? Thanks, David On

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/08/2015 09:22 AM, David Holmes wrote: Actually I'm having more doubts about this API. Library writers use finalize() as a last ditch cleanup mechanism in case the user doesn't explicitly call any "cleanup" method. So as a library writer I would think I am now expected to register my

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 8/12/2015 10:25 PM, Peter Levart wrote: On 12/08/2015 09:22 AM, David Holmes wrote: Actually I'm having more doubts about this API. Library writers use finalize() as a last ditch cleanup mechanism in case the user doesn't explicitly call any "cleanup" method. So as a library writer I

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

(once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you can (and should, I guess) just use finalize.

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/08/2015 07:41 AM, Peter Levart wrote: (once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, On 12/08/2015 08:41 AM, Peter Levart wrote: (once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, Thanks for the example and explanations. For simple cleanup of specific state values, I probably would have used lambda instead of an explicit inner class but both styles use the same mechanism. The point about using a shared cleaner can be reinforced in the example too. public

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 8, 2015, at 3:09 AM, David Holmes wrote: > > Question: what happens if an object is registered simultaneously with > multiple Cleaners? Do we need to warn the user against that? Aside: I like David's suggested "action" terminology. > Question: what happens if

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 8, 2015, at 7:44 AM, David Holmes wrote: > But thinking more on this approach this is simply not scalable. A > Cleaner per cleanable-class could result in hundreds of threads being > active! That would indeed be awful. However, the scope of a Cleaner should not

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/08/2015 04:34 PM, Roger Riggs wrote: Hi Peter, Thanks for the example and explanations. For simple cleanup of specific state values, I probably would have used lambda instead of an explicit inner class but both styles use the same mechanism. The point about using a shared cleaner can

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: > On 12/08/2015 04:34 PM, Roger Riggs wrote: >> >>private final Cleaner.Cleanable cleanable = cleaner.register(this, () >> -> fd.close()); > > Sorry Roger, but this example is flawed. This is tricky! The lambda

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/08/2015 07:25 PM, Kim Barrett wrote: On Dec 8, 2015, at 3:09 AM, David Holmes wrote: Question: what happens if an object is registered simultaneously with multiple Cleaners? Do we need to warn the user against that? Aside: I like David's suggested "action"

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, Tricky indeed, the visibility of what is captured is too subtle. Even if the field is final, it captures this, not the value. I suppose it is more efficient not to copy field values. But other than recommending capturing only local variables and arguments, is there any other relevant

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 8, 2015, at 2:26 PM, Peter Levart wrote: > > On 12/08/2015 07:25 PM, Kim Barrett wrote: >> On Dec 8, 2015, at 3:09 AM, David Holmes >> wrote: >> >>> Question: what happens if an object is registered simultaneously with >>> multiple

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/08/2015 07:44 PM, Kim Barrett wrote: On Dec 8, 2015, at 7:44 AM, David Holmes wrote: But thinking more on this approach this is simply not scalable. A Cleaner per cleanable-class could result in hundreds of threads being active! That would indeed be awful.

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 9/12/2015 5:05 PM, Peter Levart wrote: Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. Problem is that many people - myself included - would not have a clue when a lambda "captures this"! Is that part of

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Can we enhance java to allow specifying lambda capture and how the value is captured? :) This is very subtle to the point where I maybe wouldn't even encourage use of lambda in this context. sent from my phone On Dec 8, 2015 4:25 PM, "Peter Levart" wrote: > > > On

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

This has the same problem, doesn't it? The bottom line is if the lambda is () -> you're getting a capture of `this`. On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs wrote: > Hi, > > Another option that should always capture is to define a specific static > method with the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. public static class CleanerExample implements AutoCloseable { private static final Cleaner cleaner = ...; // preferably a shared cleaner

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, Another option that should always capture is to define a specific static method with the needed values as arguments: public static class CleanerExample implements AutoCloseable { FileDescriptor fd = ...; private static final Cleaner cleaner = Cleaner.create();

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/08/2015 08:08 PM, Steven Schlansker wrote: On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: On 12/08/2015 04:34 PM, Roger Riggs wrote: private final Cleaner.Cleanable cleanable = cleaner.register(this, () -> fd.close()); Sorry Roger, but this example

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi David, Thanks for the comments, Updated the javadoc and webrev with editorial changes. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html On 12/6/15 7:46 PM, David Holmes wrote: Hi Roger, Sorry to be late here but

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, Sorry to be late here but was trying not to get involved :) It is already implicit that ThreadFactory.newThread should return unstarted threads - that is what a new Thread is - so I don't think IllegalThreadStateException needs to be documented here as it is documenting behaviour

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mandy, Thanks for the comments, Updated the artifacts: [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html On 12/04/2015 08:35 PM, Mandy Chung wrote: On Dec 4, 2015, at 8:56 AM, Roger Riggs

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 03/12/15 21:47, John Rose wrote: > We are takeing a crack at it with Panama, since using C APIs > often requires timely deallocation of (non-Java) temps. Indeed it does, and I guess I'll wait. I'm a bit disappointed because I quite fancied trying to do mapped ByteBuffer.close(). While I

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Kim, On 12/3/2015 5:29 PM, Kim Barrett wrote: On Dec 3, 2015, at 4:19 PM, Roger Riggs wrote: ... src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java 237 /** 238 * Returns true if the list's next reference refers to itself. 239

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 4, 2015, at 11:56 AM, Roger Riggs wrote: > > Hi Mandy, > > The webrev[1] and javadoc[2] are updated in to address your comments. > > Thanks, Roger > > [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2]

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, Thanks for the review and comments. The webrev[1] and javadoc[2] are updated in place. Roger [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html On 12/3/2015 4:50 PM, mark.reinh...@oracle.com wrote: Looks good --

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mandy, The webrev[1] and javadoc[2] are updated in to address your comments. Thanks, Roger [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html On 12/3/2015 8:43 PM, Mandy Chung wrote: On Dec 3, 2015, at 1:19 PM,

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, On 12/04/2015 03:30 PM, Peter Levart wrote: Just a nit more, Roger: 131 * 132 * The cleaner terminates when it is unreachable and all of the 133 * registered cleaning functions are complete. (and also in the javadoc of the other create() method) The cleaner is an

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, On 12/04/2015 04:31 PM, Peter Levart wrote: ... Would writing something like the following make sense: "A future implementation may use more than one thread. The ThreadFactory should not assume that only one thread will be requested." ? I'm not sure it adds anything to talk

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/04/2015 10:04 PM, Roger Riggs wrote: Hi Peter, On 12/04/2015 03:30 PM, Peter Levart wrote: Just a nit more, Roger: 131 * 132 * The cleaner terminates when it is unreachable and all of the 133 * registered cleaning functions are complete. (and also in the javadoc of

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Just a nit more, Roger: 131 * 132 * The cleaner terminates when it is unreachable and all of the 133 * registered cleaning functions are complete. (and also in the javadoc of the other create() method) The cleaner is an object. What terminates is a thread. So what about:

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Dec 4, 2015, at 8:56 AM, Roger Riggs wrote: > > > [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html 67 * Unless otherwise noted, passing a {@code null} argument to a constructor or

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Kim, Corrected Thanks for all the review, Roger On 12/4/2015 12:56 PM, Kim Barrett wrote: On Dec 4, 2015, at 11:56 AM, Roger Riggs wrote: Hi Mandy, The webrev[1] and javadoc[2] are updated in to address your comments. Thanks, Roger [1]

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 2 Dec 2015, at 20:23, Roger Riggs wrote: > Please review the java.lang.ref.Cleaner and tests following the > recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Chris, Thanks for the review and comments: The webrev and javadoc have been updated. On 12/03/2015 08:55 AM, Chris Hegarty wrote: On 2 Dec 2015, at 20:23, Roger Riggs wrote: Please review the java.lang.ref.Cleaner and tests following the recommendation to

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, I now think that this is the right move. The simplified API is really only useful for PhantomReference(s). Since Cleaner.Cleanable interface does not provide access to the referent, it would be tempting for users to do two things at once for the same referent with Weak or Soft

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 3, 2015, at 4:19 PM, Roger Riggs wrote: > >> src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java >> 199 PhantomCleanable(CleanerImpl cleanerImpl) { >> 200 super(null, null); >> >> This feels mildly icky, passing a null referent to

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Kim, Thanks for the comments: I updated the webrev[2] and javadoc[1] with the editorial improvements. On 12/02/2015 06:20 PM, Kim Barrett wrote: On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: Please review the java.lang.ref.Cleaner and tests following the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

2015/11/25 3:42 -0800, a...@redhat.com: > On 11/24/2015 05:47 PM, Roger Riggs wrote: >> Memory is an increasingly critical resource, we should be giving >> developers more tools to manage their use of memory. The Weak and >> Soft reference forms of the cleaner make it easier to be aware of >> and

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Looks good -- thanks for the further simplification. Minor editorial comments, to add what Kim and Chris noted: - In many places you write, e.g., "Cleaner" rather than "{@code Cleaner}". For consistency with the rest of the package it'd be better in most cases just to write "cleaner"

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 3, 2015, at 1:35 PM, mark.reinh...@oracle.com wrote: > >> I'm very tempted to take a bite at this, but the above text is rather >> forbidding. I think I know how to do it. (Famous last words?) > > As the author of the above-quoted paragraph, I wish you luck. It's > a tough problem. > >

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 3 Dec 2015, at 15:58, Roger Riggs wrote: > Hi Chris, > > Thanks for the review and comments: > > The webrev and javadoc have been updated. > > On 12/03/2015 08:55 AM, Chris Hegarty wrote: >> On 2 Dec 2015, at 20:23, Roger Riggs wrote: >>

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Dec 3, 2015, at 1:19 PM, Roger Riggs wrote: > > [1] http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > [2] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ The implementation looks good. I’ll wait for an updated javadoc and re-review that incorporates

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, Should the javadocs in the Cleaner methods include NPE given they use Objects.requireNonNull? Best Lance On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: > Please review the java.lang.ref.Cleaner and tests following the > recommendation to simplify the public

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Lance, Cleaner class level javadoc defines the behavior: "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." Roger On 12/02/2015 04:09 PM, Lance Andersen wrote: Hi Roger,

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: > > Please review the java.lang.ref.Cleaner and tests following the > recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: >

Re: Promptly cleaning direct ByteBuffer(s) - was: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 11/25/2015 03:45 PM, Roger Riggs wrote: > Prompt cleanup can't rely on GC. Yes, that's the key. If people need prompt cleanup, they *really* need it because they've run out of memory or address space. Best effort won't do it. Andrew.

Re: Promptly cleaning direct ByteBuffer(s) - was: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, Seems like a reprise from September of "Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)". Prompt cleanup can't rely on GC. Roger On 11/25/2015 10:31 AM, Peter Levart wrote: Changing the subject to not hijack the thread... On 11/25/2015 01:54 PM, Andrew Haley

Promptly cleaning direct ByteBuffer(s) - was: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Changing the subject to not hijack the thread... On 11/25/2015 01:54 PM, Andrew Haley wrote: On 11/25/2015 12:39 PM, Peter Levart wrote: What do you think? It's very problematic. First off, collection often clears the young generation altogether, promoting everything. This could be a

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 11/25/2015 12:42 PM, Andrew Haley wrote: On 11/24/2015 05:47 PM, Roger Riggs wrote: Memory is an increasingly critical resource, we should be giving developers more tools to manage their use of memory. The Weak and Soft reference forms of the cleaner make it easier to be aware of and

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 11/25/2015 12:39 PM, Peter Levart wrote: > What do you think? It's very problematic. First off, collection often clears the young generation altogether, promoting everything. Secondly, I think we are already short of header bits in some cases. Thirdly, this requires all collectors to be

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 11/24/2015 05:47 PM, Roger Riggs wrote: > Memory is an increasingly critical resource, we should be giving > developers more tools to manage their use of memory. The Weak and > Soft reference forms of the cleaner make it easier to be aware of > and respond to increased memory pressure. > >

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mark, Memory is an increasingly critical resource, we should be giving developers more tools to manage their use of memory. The Weak and Soft reference forms of the cleaner make it easier to be aware of and respond to increased memory pressure. The management of memory is not

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

2015/11/24 5:42 -0800, peter.lev...@gmail.com: > On 11/24/2015 02:12 PM, Peter Levart wrote: >> What is actually the reason for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8024421 >> >> to have the resolution: "Won't Fix"? > > ...I see there are further developments on

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mark, Memory is an increasingly critical resource, we should be giving developers more tools to manage their use of memory. The Weak and Soft reference forms of the cleaner make it easier to be aware of and respond to increased memory pressure. The management of memory is not

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, On 11/23/2015 11:32 PM, mark.reinh...@oracle.com wrote: ( Finally getting back to this, after too many weeks of travel ... ) 2015/10/20 11:28 -0700, roger.ri...@oracle.com: Sorry for the silence, JavaOne preparations and the availability of folks who wanted to review have stretched things

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 11/24/2015 02:12 PM, Peter Levart wrote: What is actually the reason for the following issue: https://bugs.openjdk.java.net/browse/JDK-8024421 to have the resolution: "Won't Fix"? ...I see there are further developments on this front: https://bugs.openjdk.java.net/browse/JDK-8071507

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

( Finally getting back to this, after too many weeks of travel ... ) 2015/10/20 11:28 -0700, roger.ri...@oracle.com: > Sorry for the silence, JavaOne preparations and the availability of > folks who wanted to review have stretched things out. > > The Cleaner API was very simple and saw feature

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 11/03/2015 10:42 PM, Roger Riggs wrote: I’m in two minds that it sounds sensible for this Cleaner API to extend for soft/weak references whereas I am not certain of the use cases. Anyone can share the known use cases that would be helpful. Besides the cases already mentioned on the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mandy, A couple of followups below... On 11/3/2015 4:18 PM, Mandy Chung wrote: On Nov 3, 2015, at 12:32 PM, Roger Riggs wrote: Hi Mandy, On 11/2/2015 2:53 PM, Mandy Chung wrote: On Oct 20, 2015, at 11:28 AM, Roger Riggs wrote: Updated

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Nov 3, 2015, at 12:32 PM, Roger Riggs wrote: > > Hi Mandy, > > On 11/2/2015 2:53 PM, Mandy Chung wrote: >>> On Oct 20, 2015, at 11:28 AM, Roger Riggs >>> wrote: >>> >>> Updated Javadoc: >>> >>>

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mandy, On 11/2/2015 2:53 PM, Mandy Chung wrote: On Oct 20, 2015, at 11:28 AM, Roger Riggs wrote: Updated Javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc/ I’m happy with this API to provide an easy way to migrate away from finalizers. Some thoughts: 1.

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, Here's a demonstration that shows the "reachability" race: import java.lang.ref.ReferenceQueue; import java.lang.ref.WeakReference; /** * A demonstration of WeakReference initialization race */ public class WeakRace extends WeakReference { static volatile boolean pause; int

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Oct 20, 2015, at 11:28 AM, Roger Riggs wrote: > > Updated Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ I’m happy with this API to provide an easy way to migrate away from finalizers. Some thoughts: 1. For an existing finalizer (say cleanup

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, I've always assumed that the arguments could not be gc'd at least until the method returns in part because the caller was holding references. But I suppose in a completely inlined case an optimizer might try to make more relaxed conclusions. Since the new object has not yet been

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

I think this issue is specific to References since they're not treated as strong roots by GC and therefore do not participate in strong reachability graphs. On Wed, Oct 21, 2015 at 10:52 AM, Roger Riggs wrote: > Hi Andrew, > > So then is is correct to conclude that the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 10/21/2015 02:58 PM, Daniel Fuchs wrote: > I do hope that method parameters are not eagerly gc'ed before > the method returns They are -- that's what reachabilityFence() is for. I don't think that constructors have any special rules, and nor should they. Andrew.

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Andrew, So then is is correct to conclude that the gc does examine fields in instances still being constructed to determine reachability? How is that we have gone so long without needing reachabilityFence? Or is it just because optimizers have taken so long to get a perfect view of

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, On 10/21/2015 4:02 AM, Peter Levart wrote: Hi Roger, I think this is a good compromise. Having the low-level extended functionality in the JDK for internal use until it is proven. Dropping Cleanable.clear() is also a correct move. I currently don't see a use for it. If one

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, Peter, On 21/10/15 15:38, Roger Riggs wrote: Hi Peter, I've always assumed that the arguments could not be gc'd at least until the method returns in part because the caller was holding references. But I suppose in a completely inlined case an optimizer might try to make more relaxed

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 10/21/2015 03:52 PM, Roger Riggs wrote: > So then is is correct to conclude that the gc does examine fields in > instances > still being constructed to determine reachability? Oh sure, it has to. The issue here is that the object being constructed is a weak reference, and therefore its

  1   2   >