Bug ID: JDK-7011178 Expand on supports_cx8 to have supports_atomic_long

Versions (Unresolved/Resolved/Fixed)

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.

Other
hs25Resolved

The VM uses supports_cx8 (named from the x86 cmpxchg8 operation that allows 64-bit CAS on 32-bit systems) as a proxy for "supports atomic 64-bit operations on Java longs". In addition to being used for compare-and-set operations on Java longs, it is also used within unsafe.cpp to control atomic load/store of Java longs.

The recent fix of 7009756 correctly implemented the atomic load/store aspects of this for the case where supports_cx8 is true and it was proposed to change the test from supports_cx8 to a more specific supports_atomic_<type>_ops, as it was pointed out that platforms can support 64-bit load/store even if they don't support 64-bit CAS. However due to timing constraints with the HS20 schedule it was not feasible to make that change at that time.

This CR now proposes to clean up the current code by defining the necessary supports_atomic_XXX_ops and in the process remove the CPU-based ifdefs that were put in.

John Rose has pointed out that the reason that the load/store operations are conditional on supports_cx8 is because whatever mechanism is used for atomic load/store of 64-bit values must be consistent with the atomicity mechanism used for cmpxchg8 when supports_cx8 is not true. In simple terms if locking is used on these systems then locking must also be used for the simple load/stores otherwise the cmpxchg8 will be broken if direct stores are used in conjunction with the cmpxchg8. This applies to both the methods in Unsafe and whatever mechanism is implemented in the interpreter/compiler for Java volatile long/double support.
05-05-2013
All platforms are required to support 64-bit atomic load/store to support Java volatile long and double accesses. Whatever mechanism is used for that should also be used in the Unsafe code that is currently special-cased based on platform, and conditionalized using supports_cx8. That special case code can simply be removed. If there were an argument to keep it then it should be changed to use supports_atomic_long_ops, not supports_cx8 - but I don't see any reason to keep it.
25-04-2013
SUGGESTED FIX Unsafe.cpp always uses OrderAccess::load_acquire(jlong) and OrderAccess::release_store_fence(jlong, jlong) for volatile get/set of Java long values. OrderAccess in turn relies on Atomic::load/store for jlong.
04-04-2011
EVALUATION The original suggested fix is actually superfluous. All VMs are required to support atomic_long_access to implement Java volatile semantics for Java longs. All we need to do here (in Unsafe) is remove the VM_Version::supports_cx8 check for get/put operations on volatiles and defer to the OrderAccess::load_acquire and OrderAccess::release_store_fence operations. These in turn must use Atomic::load(jlong) and Atomic::store(jlong, jlong) which will use whatever facilities are presently used by the interpreter/C1/C2 to perform the atomic accesses (eg, using the FP-unit on x86).
04-04-2011
SUGGESTED FIX Add VMVersion::supports_atomic_long_access() which by default will return the same as supports_cx8. Modify the long versions of the Unsafe methods to use the new query and remove the checks for x86/sparc.
11-01-2011
EVALUATION See suggested fix
11-01-2011

Relates :	JDK-7143664 - Clean up OrderAccess implementations and usage
Relates :	JDK-7009756 - volatile variables could be broken throw reflection API