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

[Roger Riggs]

Hi Remi,

That was the initial implementation.  However, it was being invoked
during startup before Lambda was initialized and resulted in an 
ExceptionInInitializer.

We don't have a good handle on when it is too early to use lambda except 
by trial and error.
I think there are some improvements in the works so that some simple 
cases of Lambda
can be used earlier and will see if they apply.

Thanks, Roger



On 10/13/2015 4:11 AM, Remi Forax wrote:
> Hi Roger,
>
> I agree with comments from Mark and Mandy,
> you can also simplify your code by using a lambda instead of a class to implement the thread factory.
>
> public static Cleaner create() {
>    return create(runnable ->  {
>        return AccessController.doPrivileged((PrivilegedAction<Thread>) () -> {
>          Thread t = new InnocuousThread(runnable);
>          t.setName("Cleaner-" + t.getId());
>          return t;
>        });
>    });
> }
>
> given that the lambda (the one that takes a Runnable) doesn't capture anything,
> it will be considered as a constant by the VM, so no need to implement the singleton pattern, here.
>
> cheers,
> Rémi
>
> ----- Mail original -----
>> De: "Mandy Chung" <mandy.chung at oracle.com>
>> À: "mark reinhold" <mark.reinhold at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Envoyé: Mardi 13 Octobre 2015 03:12:26
>> Objet: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use	alternative to finalization
>>
>>
>>> On Oct 12, 2015, at 12:30 PM, mark.reinhold at oracle.com wrote:
>>>
>>> 2015/10/8 1:41 -0700, roger.riggs at oracle.com:
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/
>>>>
>>>> javadoc:
>>>>     http://cr.openjdk.java.net/~rriggs/cleaner-doc2/
>>> Roger -- thanks for taking this on.  The more we can do to get people
>>> to stop using sun.misc APIs, the better.
>>>
>>> A couple of comments/questions:
>>>
>>> First, I think the approach in your first version is, well, cleaner.
>> +1
>>
>> I started reviewing the first version and pondering on the benefits of the
>> new versions.
>>
>>
>>> The additional abstract classes in the second version look like a
>>> classic case of implementation inheritance that's not subtype
>>> inheritance, what with the overrides of the original enqueue and
>>> isEnqueued methods to throw UnsupportedOperationException.
>>>
>>> I understand the desire to avoid allocating too many objects, but
>>> do we have actual use cases where that's critical?  The original
>>> sun.misc.Cleaner has been used by both internal and external code
>>> to do relatively heavy-weight things like unmap direct buffers and
>>> release other kinds of native resources, which suggests that
>>> allocating three small objects per cleaner is not a problem.
>>>
>>> Second, the original sun.misc.Cleaner only handles phantom references.
>>> What are the use cases for weak and soft cleaners?
>>>
>>> Finally, how important is it to be able to unregister a cleaner?  In
>>> all the years we've had sun.misc.Cleaner that capability has never
>>> been needed, and leaving it out would simplify the API.
>> If there is no strong need of unregister a cleaner, Cleaner API won’t need to
>> return a Cleanable object which I think it’s nice and simpler.
>>
>> Mandy
>>
>>