Currently, trying to use Atomic::add with 64-bit value/destination on 32-bit platform would fail to build with obscure linkage error, because these operations are not implemented for 32-bit platforms. This is an ongoing hassle when developing generic VM code: the 64-bit systems work well, and developers usually discover this pitfall when building/testing 32-bit builds. atomic.hpp suggests to conditionalize the caller code on supports_cx8(), but hardly anyone remembers to do it.

64-bit Atomic::cmpxchg is implemented on almost all platforms, though, which means we can write the fallback implementations for 64-bit add and xchg using 64-bit cmpxchg. When 64-bit cmpchg is not available, we can do what Access API does: take a lock.

This would simplify future development.

The caveat with such delegation would be giving up on wait-freedom that hardware implementations for xadd/xchg implicitly have. Implementing xadd/xchg with CAS loops makes them lock-free, but not wait-free. Implementing them with locks makes them not lock-free. This might not be a problem in practice.

Existing code in this area:
 1. Fallback implementations for e.g. Unsafe::getAndAdd and Unsafe::getAndSet already do fallback CAS loops: https://github.com/openjdk/jdk/blob/1f7dfda7059f9dc14bff61b3c77d769ade85557d/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L2471-L2507
 2. Access API takes a lock: https://github.com/openjdk/jdk/blob/1f7dfda7059f9dc14bff61b3c77d769ade85557d/src/hotspot/share/oops/accessBackend.inline.hpp#L217-L253

A draft version for Atomic::add and CAS loops looks like this:
https://github.com/openjdk/jdk/compare/master...shipilev:wip-32bit-add