| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2174825 | 6u14 | Abhijit Saha | P3 | Closed | Fixed | b01 |
| JDK-2172209 | 6u5p | Abhijit Saha | P3 | Closed | Fixed | b01 |
When run with -XX:+CacheTimeMillis the attached testcase appears to lose time because the cached time is not getting updated after ~4 seconds into the run.
It is caused by the following. The EnableBiasedLocking PeriodicTask runs on the Watcher thread when BiasedLockingStartupDelay > 0. It attempts to synchronously reach a safepoint, blocking the watcher thread, after the delay. If a safepoint cannot be reached relatively quickly, since CacheTimeMillis relies on a responsive watcher thread, the cached time may not get updated promptly.
It is caused by the following. The EnableBiasedLocking PeriodicTask runs on the Watcher thread when BiasedLockingStartupDelay > 0. It attempts to synchronously reach a safepoint, blocking the watcher thread, after the delay. If a safepoint cannot be reached relatively quickly, since CacheTimeMillis relies on a responsive watcher thread, the cached time may not get updated promptly.
- backported by
-
JDK-2172209 EnableBiasedLocking with BiasedLockingStartupDelay can block Watcher thread
-
- Closed
-
-
-
- Closed
-
- relates to
-
JDK-5014723 implement "strip mining" loop optimization
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-