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
[2]
http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.03/
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
allocation
java/nio/file/spi/SetDefaultProvider.java: Unit test for
java.nio.file.spi.FileSystemProvider
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