JDK-6822204 : volatile fences should prefer lock:addl to actual mfence instructions
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: hs15
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- OS: solaris_9
- CPU: x86
- Submitted: 2009-03-25
- Updated: 2016-04-19
- Resolved: 2009-04-08
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 | JDK 7 | Other |
|---|---|---|
6u18Fixed  |
7Fixed |
hs15Fixed |
Related Reports
|
Relates :
|
Description
When generating code for volatile memory accesses on x86 we currently use the mfence instruction if it is available and fall back to a lock:addl [esp], 0 when it's not. For the purposes of volatile synchronization they are equivalent in power but on some processors the mfence is more expensive so we should prefer the lock:addl idiom.
Comments
|