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.ch...@oracle.com> wrote:
On Feb 15, 2016, at 9:06 AM, Uwe Schindler <uschind...@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.
