GHA testing shows that there are still intermittent failures on NonInterruptibleInterruptTest, mostly with executor-fjp.
```
invokeAPI(org.openjdk.jmh.it.interrupts.NonInterruptibleInterruptTest) Time elapsed: 38.465 sec <<< ERROR!
org.openjdk.jmh.runner.RunnerException: Benchmark caught the exception
at org.openjdk.jmh.runner.Runner.runBenchmarks(Runner.java:572)
at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:309)
at org.openjdk.jmh.runner.Runner.run(Runner.java:185)
at ...
Suppressed: java.lang.Exception: java.lang.InterruptedException
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:551)
at ...
Caused by: java.lang.InterruptedException
at java.base/java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:212)
at java.base/java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:363)
at org.openjdk.jmh.runner.BenchmarkHandler.getWorkerData(BenchmarkHandler.java:459)
...
```
Reproduces well on Linux with:
% taskset -c 0,1 mvn clean install -pl jmh-core-it -am -Dtest=NonInterruptibleInterruptTest -DfailIfNoTests=false -P executor-fjp
The root cause is that sometimes we do not reach any interrupt-checking method after benchmark exits and slides towards the exit. This would make a new barrier code capture the interrupts, like in the case above. This is actually a problem for the next iteration too: the iteration might finish too soon by catching the interrupt from previous timing-out iteration.
```
invokeAPI(org.openjdk.jmh.it.interrupts.NonInterruptibleInterruptTest) Time elapsed: 38.465 sec <<< ERROR!
org.openjdk.jmh.runner.RunnerException: Benchmark caught the exception
at org.openjdk.jmh.runner.Runner.runBenchmarks(Runner.java:572)
at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:309)
at org.openjdk.jmh.runner.Runner.run(Runner.java:185)
at ...
Suppressed: java.lang.Exception: java.lang.InterruptedException
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:551)
at ...
Caused by: java.lang.InterruptedException
at java.base/java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:212)
at java.base/java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:363)
at org.openjdk.jmh.runner.BenchmarkHandler.getWorkerData(BenchmarkHandler.java:459)
...
```
Reproduces well on Linux with:
% taskset -c 0,1 mvn clean install -pl jmh-core-it -am -Dtest=NonInterruptibleInterruptTest -DfailIfNoTests=false -P executor-fjp
The root cause is that sometimes we do not reach any interrupt-checking method after benchmark exits and slides towards the exit. This would make a new barrier code capture the interrupts, like in the case above. This is actually a problem for the next iteration too: the iteration might finish too soon by catching the interrupt from previous timing-out iteration.
- links to
-
Review openjdk/jmh/112