RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Peter Levart peter.levart at gmail.com
Tue Feb 16 16:15:23 UTC 2016

Hello everybody,

Thanks for looking into this and for all your comments. Now that it 
seems we have a consensus that replacing internal Cleaner with public 
Cleaner is not a wrong idea, I created an issue for it [1] so that we 
may officially review the implementation. I also created an updated 
webrev [2] which fixes some comments in usages that were not correct any 
more after the change. I also took the liberty to modify the 
CleanerImpl.InnocuousThreadFactory to give names to threads in 
accordance to the style used in some other thread factories (Timer-0, 
Timer-1, ..., Cleaner-0, Cleaner-1, ..., etc.). This gives the thread of 
internal Cleaner instance, which is now constructed as part of the 
boot-up sequence, a stable name: "Cleaner-0".

If you feel that internal Cleaner instance should have a Thread with 
MAX_PRIORITY, I can incorporate that too.

[1] https://bugs.openjdk.java.net/browse/JDK-8149925

I re-ran the java/lang/ref and java/nio tests and all pass except two 
ignored tests:

java/nio/Buffer/LimitDirectMemory.sh: Test option to limit direct memory 
java/nio/file/spi/SetDefaultProvider.java: Unit test for 

and the following two, which seem to not like my network config. or 
something like that:

java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java: Unit 
test for DatagramChannel's multicast support
java/nio/channels/DatagramChannel/Promiscuous.java: Test for 
interference when two sockets are bound to the same port but joined to 
different multicast groups

Regards, Peter

On 02/16/2016 03:02 PM, Chris Hegarty wrote:
> On 15 Feb 2016, at 20:05, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> On Feb 15, 2016, at 9:06 AM, Uwe Schindler <uschindler at apache.org> wrote:
>>> Hi,
>>>> On 15/02/2016 14:57, Chris Hegarty wrote:
>>>>> Peter,
>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/
>> This patch looks correct to me.  The innocuous thread created for common cleaner is of Thread.MAX_PRIORITY - 2 priority whereas the reference handler thread is of MAX_PRIORITY priority.
> I see your point, but I don’t see this as an issue because threads failing to
> allocate memory themselves get involved in cleaning. So pressure is
> somewhat off the reference handler thread.
> -Chris.

More information about the core-libs-dev mailing list