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

Roger Riggs Roger.Riggs at Oracle.com
Tue Dec 15 16:00:56 UTC 2015


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 needs do not prevent the object from becoming phantom reachable.
>
> 1) The "after it" looks like a leftover from an edit
> 2) "becomes phantom reachable" after already "becoming phantom 
> reachable" needs clarification to make sense:
Yes, this poorly worded.  It has been simplified in the latest update.

>
> My suggestion:
>
> * The cleaning function is invoked after the object it is cleaning 
> becomes
> * phantom reachable, so it is important that the object's references 
> and values
> * do not prevent the object from remaining phantom reachable.
>
> PS: I noticed in the source that much of the documentation is written 
> with line breaks but without the <p> tag. If you have a paragraph in 
> mind, perhaps you can remove the line breaks so it doesn't look like 
> <p> tags were meant to be there but forgotten.
Blank lines improve readability of the source; but should not appear to 
break any paragraph.
Did I miss some?

Thanks, Roger

>
> Cheers,
> Paul
>
> On Tue, Dec 15, 2015 at 1:01 AM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
>
>     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/
>         <http://cr.openjdk.java.net/%7Erriggs/webrev-cleaner-8138696/>
>         [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html
>         <http://cr.openjdk.java.net/%7Erriggs/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 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 {
>
>                              private static final Cleaner cleaner =
>                     ...; // preferably a
>                     shared cleaner
>
>                              private final PrivateNativeResource pnr;
>
>                              private final Cleaner.Cleanable cleanable;
>
>                              public CleanerExample(args, ...) {
>
>                                  // prepare captured state as local
>                     vars...
>                                  PrivateNativeResource _pnr = ...;
>
>                                  this.cleanable =
>                     cleaner.register(this, () -> {
>                                      // DON'T capture any instance
>                     fields with lambda since
>                     that would
>                                      // capture 'this' and prevent it
>                     from becoming
>
>
>                 I assume that the WARNING should include anonymous
>                 inner classes too
>                 ( which I expect are quite common, though less now
>                 with lambda ) ?
>
>                 Is "leaking" 'this' in a constructor a potential issue
>                 with respect
>                 to the visibility of pnr? As well as causing
>                 red-squiggly lines in
>                 the IDE ;-)
>
>
>             'this' only leaks to the 'referent' field of
>             PhantomReference where by
>             definition is not accessible.
>
>             'this' can become phantom-reachable before CleanerExample
>             constructor
>             ends. But this is harmless, because the code that may
>             execute at that
>             time does not access the object any more, so the object
>             may be safely
>             collected.
>
>             Cleanup action can run at any time after registration even
>             before
>             CleanerExample constructor ends. But this is harmless too,
>             because it
>             only accesses PrivateNativeResource which is fully
>             constructed before
>             registration of cleanup action.
>
>             I see no issues apart from IDE(s) not seeing no issues.
>
>             Regards, Peter
>
>
>                 -Chris.
>
>
>                     phantom-reachable!!!
>                                      _pnr.close();
>                                  });
>
>                                  this.pnr = _pnr;
>                              }
>
>                              public void close() {
>                                  cleanable.clean();
>                              }
>
>
>                     Regards, Peter
>
>
>
>




More information about the core-libs-dev mailing list