JDK-8164159 : java/nio/file/WatchService/UpdateInterference.java test leaves daemon threads
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-08-16
  • Updated: 2016-09-02
  • Resolved: 2016-08-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b134Fixed
Related Reports
Relates :  
JDK-8162757 - sun/net/www/protocol/http/NoCache.java failed due to timeout
Relates :  
JDK-8160642 - sun/security/tools/jarsigner/warnings/HasUnsignedEntryTest.java failed with timeout
Description
java/nio/file/WatchService/UpdateInterference.java test creates a couple of daemon threads which have an infinite loop inside. When the test finishes, those daemon still keep running as long as jtreg use this instance of JVM to run other tests (the test doesn't run in othervm mode).

The test also creates a WatchService which creates a "FileSystemWatchService" daemon thread. Then, the test doesn't close this WatchService, and as a result, this daemon thread keeps running as well.

The test shouldn't leave daemon threads when it finishes. It may slow down further test execution. If other tests also leave daemon threads, it may cause intermittent test failures, see for example JDK-8160642 and JDK-8162757.
Comments
Code review: http://mail.openjdk.java.net/pipermail/nio-dev/2016-August/003835.html
18-08-2016
If there threads left spinning (not blocked or blocking for tiny periods) then it might slow down the overall test runs. We've had a few of these issues in the past with buggy tests. In this case then it's just blocked threads left behind so I doubt they slow down the test runs. No issue with getting tests to clean-up of course.
17-08-2016
Please see logs attached to JDK-8160642 https://bugs.openjdk.java.net/secure/attachment/62320/HasUnsignedEntryTest.jtr.txt jstack output showed lots of daemon threads which didn't seem to be started by HasUnsignedEntryTest.java. Since the test doesn't run in othervm mode, I suppose those daemon threads were created by other test which were run in this jvm earlier. If I understand it correctly, such daemon threads consume some resources even if they just waif for events. As a result, this (+ other possible factors) may slow down test execution, and sometimes result to timeouts (please see also similar JDK-8162757). Am I missing something?
17-08-2016
The daemon threads are harmless as the threads block waiting for events.
17-08-2016
Suggested fix: http://cr.openjdk.java.net/~asmotrak/8164159/webrev.00/
16-08-2016
Here is a piece of jstack output for the test: "Thread-2" #16 daemon prio=5 os_prio=0 tid=0x00007f157804a000 nid=0x2b29 in Object.wait() [0x00007f15adaf9000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(java.base@9-internal/Native Method) - waiting on <no object reference available> at java.lang.Object.wait(java.base@9-internal/Object.java:516) at sun.nio.fs.AbstractPoller$Request.awaitResult(java.base@9-internal/AbstractPoller.java:200) - waiting to re-lock in wait() <0x00000006d6712cc8> (a sun.nio.fs.AbstractPoller$Request) at sun.nio.fs.AbstractPoller.invoke(java.base@9-internal/AbstractPoller.java:229) at sun.nio.fs.AbstractPoller.register(java.base@9-internal/AbstractPoller.java:129) at sun.nio.fs.LinuxWatchService.register(java.base@9-internal/LinuxWatchService.java:90) at sun.nio.fs.UnixPath.register(java.base@9-internal/UnixPath.java:891) at java.nio.file.Path.register(java.base@9-internal/Path.java:781) at UpdateInterference$2.run(UpdateInterference.java:76) "Thread-1" #15 daemon prio=5 os_prio=0 tid=0x00007f1578048800 nid=0x2b28 waiting on condition [0x00007f15adbfa000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(java.base@9-internal/Native Method) at UpdateInterference$1.run(UpdateInterference.java:59) "FileSystemWatchService" #14 daemon prio=5 os_prio=0 tid=0x00007f157803e800 nid=0x2b27 runnable [0x00007f15adcfb000] java.lang.Thread.State: RUNNABLE at sun.nio.fs.UnixNativeDispatcher.read(java.base@9-internal/Native Method) at sun.nio.fs.LinuxWatchService$Poller.run(java.base@9-internal/LinuxWatchService.java:320) at java.lang.Thread.run(java.base@9-internal/Thread.java:843)
16-08-2016