-
Bug
-
Resolution: Fixed
-
P2
-
8-shenandoah, 11-shenandoah, 14, 15
-
b27
-
Not verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8248083 | 16 | Aleksey Shipilev | P2 | Resolved | Fixed | team |
| JDK-8249108 | 14u-cpu | Aleksey Shipilev | P2 | Resolved | Fixed | master |
| JDK-8248953 | 14.0.2 | Aleksey Shipilev | P2 | Resolved | Fixed | b12 |
This was originally found by Aditya Mandaleeka when running sh/jdk11 tests. It seems to reproduce as the very rare timeout in java/security/Provider/GetServiceRace.java test. The underlying reason is that pacer does this:
JavaThread::current()->sleep(cur);
...which in turn checks and *clears* the interrupt status in the guts of OS code:
if (os::is_interrupted(thread, true)) { // "true" means clear interrupt status
return OS_INTRPT;
}
And that interferes with interrupt status of Java thread. This is incorrect.
JavaThread::current()->sleep(cur);
...which in turn checks and *clears* the interrupt status in the guts of OS code:
if (os::is_interrupted(thread, true)) { // "true" means clear interrupt status
return OS_INTRPT;
}
And that interferes with interrupt status of Java thread. This is incorrect.
- backported by
-
JDK-8248083 Shenandoah: pacer should not affect interrupt status
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
-
- Closed
-
-
JDK-8247367 Shenandoah: pacer should wait on lock instead of exponential backoff
-
- Resolved
-