JDK-8293940 : Some tests for virtual threads take too long
  • Type: Bug
  • Component: core-libs
  • Affected Version: 20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-09-16
  • Updated: 2022-12-22
  • Resolved: 2022-09-30
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 20
20 b18Fixed
Related Reports
Relates :  
JDK-8294375 - test/jdk/java/nio/channels/vthread/BlockingChannelOps.java is slow
Relates :  
JDK-8293885 - Review running times of tier 1 library regression tests (umbrella)
Relates :  
JDK-8294146 - Review running times of virtual thread regression tests
Description
A number of the tests added to test virtual threads in JDK 19 have long execution times.

vthread/BlockingChannelOps and vthread/BlockingSocketOps take the longest time as they run a lot tests and need to run in several configurations. This is tracked by JDK-8294375.

This issue tracks improvements to:

jdk/jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java
jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java
jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
jdk/java/util/concurrent/ExecutorService/CloseTest.java
jdk/java/lang/Thread/virtual/ThreadAPI.java

and the stress/reliability tests in jdk/java/lang/Thread/virtual/stress.

StructuredTaskScopeTest, ThreadFlockTest and ThreadPerTaskExecutorTest run a lot of tests with thread factories for both platform and virtual threads. These can be split into two runs, and some of the delays used by some of their tests can be reduced without impacting the reliability of the tests.

CloseTest has sleeps that mostly not needed.

ThreadAPI has several sleeps to improve the chances that a virtual thread is parked/blocked. These sleeps can be replaced with code that polls the thread state. In addition, testing the duration of Thread.sleep can be reduced to two cases. These could run concurrently but it would make the test harder to debug in the event of a test failure.

The stress tests in jdk/java/lang/Thread/virtual/stress are proving very useful to catch issues in both hotspot and library code. Most have an iteration count and some can be dialled down for release builds. This issue does not propose to change the iteration count for debug builds at this time.
Comments
Changeset: b8f9a915 Author: Alan Bateman <alanb@openjdk.org> Date: 2022-09-30 16:41:33 +0000 URL: https://git.openjdk.org/jdk/commit/b8f9a915a2bfd0f7920ecfc5b3a08670df5f9f3e
30-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10463 Date: 2022-09-28 08:07:25 +0000
29-09-2022