P3
TimedWaitingTest frequently fails in GitHub Actions:
```
java.lang.IllegalStateException: Thread.join was too short: 999 ms
```
It detects that a waiting call lasted for 999 ms instead of requested 1000 ms which is not in line with the specification. The failing methods differ (Thread.join, Thread.wait, ReentrantLock.tryLock...) but the actual waiting time is always 999 ms.
There is a possibility that the problem is that the test uses non-monotonic `System.currentTimeMillis()` to measure the time, while the waiting functions use `System.nanoTime()` (which CRaC offsets to ensure its monotonicity, also using System.currentTimeMillis() in the process). It is, in theory, possible that System.currentTimeMillis() would jump back after it was used for the offsetting and cause the failure. Although in reality the chances are pretty low since no one intentionally changes the time in the test environment and NTP should only slow the time down in case of a difference of just 1 ms instead of making it jump back.
Anyway, it would be more correct to use a monotonic clock for the measurements the test performs.
```
java.lang.IllegalStateException: Thread.join was too short: 999 ms
```
It detects that a waiting call lasted for 999 ms instead of requested 1000 ms which is not in line with the specification. The failing methods differ (Thread.join, Thread.wait, ReentrantLock.tryLock...) but the actual waiting time is always 999 ms.
There is a possibility that the problem is that the test uses non-monotonic `System.currentTimeMillis()` to measure the time, while the waiting functions use `System.nanoTime()` (which CRaC offsets to ensure its monotonicity, also using System.currentTimeMillis() in the process). It is, in theory, possible that System.currentTimeMillis() would jump back after it was used for the offsetting and cause the failure. Although in reality the chances are pretty low since no one intentionally changes the time in the test environment and NTP should only slow the time down in case of a difference of just 1 ms instead of making it jump back.
Anyway, it would be more correct to use a monotonic clock for the measurements the test performs.
- links to
-
Review(crac)
openjdk/crac/209