P4
runtime/ThreadCountLimit.java, introduced with JDK-8222671, caused a number of problems on our test machines.
(JDK-8222671 is private and cannot be accessed from outside Oracle, so all I know comes from its review thread [1]).
The test creates massive amount of threads in the hope of hitting some limit which should manifest as an OOM. This affects unrelated processes, unless the test is executed in a jail or with specific limits set.
This test probably should be executed with a specific limit, but for now lets mark it as @stress and remove it from tier1 tests.
[1] http://openjdk.5641.n7.nabble.com/RFR-8222671-thread-large-thread-large-java-times-out-on-MacOSX-td418526.html
(JDK-8222671 is private and cannot be accessed from outside Oracle, so all I know comes from its review thread [1]).
The test creates massive amount of threads in the hope of hitting some limit which should manifest as an OOM. This affects unrelated processes, unless the test is executed in a jail or with specific limits set.
This test probably should be executed with a specific limit, but for now lets mark it as @stress and remove it from tier1 tests.
[1] http://openjdk.5641.n7.nabble.com/RFR-8222671-thread-large-thread-large-java-times-out-on-MacOSX-td418526.html
- relates to
-
JDK-8293872 Make runtime/Thread/ThreadCountLimit.java more robust
-
- Resolved
-
