JDK-6666698 : EnableBiasedLocking with BiasedLockingStartupDelay can block Watcher thread
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 7
- Priority: P3
- Status: Closed
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2008-02-22
- Updated: 2011-04-20
- Resolved: 2011-04-20
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 6 | Other |
|---|---|
6u14Fixed  |
hs12Fixed |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
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.
Comments
|