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.
JDK 6 JDK 7 Other
6u18Fixed 7Fixed hs15Fixed
Related Reports
Relates :  
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.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d0994e5bebce

EVALUATION The fix is to put the logic for using lock:addl into membar and use membar in the appropriate places. mfence should always generate mfence.