sun.misc.Unsafe provides a set of API's for atomic updates to fields including Java long fields. Not all platforms support the atomic compare-and-set for 64-bit values in which case Unsafe will fallback to a locking scheme. The locking scheme can not enforce atomicity with respect to direct stores to the field from Java code, so clients of this API should avoid such direct stores.

I did an audit of j.u.c to see which classes use Unsafe.compareAndSwapLong and whether they allow direct setting of the field that is cas'd. The following classes (and any apps that use them) are potentially broken because they allow that:

- AtomicLong
- AbstractLongQueuedSynchronizer
- StampedLock

The set-style operations and any internal direct sets (eg in StampedLock) would need to be rewritten to use Unsafe.putLongVolatile. Any use of putLongVolatile should be factored and guarded by "supports_cx8" so that the JIT can inline the direct volatile store when it is available.

NOTE this only affects platforms which do not support 64-bit CAS. None of the mainline OpenJDK platforms are affected by this.

Also note that other j.u.c classes already take this into account, either ensuring Unsafe.xxx updates only or even using Java-level locking in the case of AtomicLongFieldUpdater.