JDK-8130728 : Disable WorkAroundNPTLTimedWaitHang by default
- Type: Enhancement
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 9
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2015-07-08
- Updated: 2015-12-18
- Resolved: 2015-07-13
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 9 |
|---|
9 b75Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
The workaround triggered by WorkAroundNPTLTimedWaitHang (an experimental flag set to 1 by default) was to alleviate a hang that could occur on a pthread_cond_timedwait on LInux, if the timeout value was a time in the past - see JDK-6314875. This glibc bug was fixed in 2005 in glibc 2.3.5-3 https://lists.debian.org/debian-glibc/2005/08/msg00201.html but the workaround persists and was (unfortunately) copied into the BSD and AIX ports. It is time to remove that workaround but before we can do that we need to be sure that we are not in fact hitting the workaround code. To that end I propose to use this bug to switch the flag's value to 0 to verify correct operation. If that goes well then we can remove the code either later in JDK 9 or early in JDK 10.