Bug ID: JDK-8203283 Provide 8-byte Atomic::add fallback for 32-bit platforms

Type: Enhancement
Component: hotspot
Sub-Component: runtime
Affected Version: 11

Priority: P3
Status: Open
Resolution: Unresolved

Submitted: 2018-05-16
Updated: 2021-08-03

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
tbdUnresolved

Currently, trying to use Atomic::add over 64-bit value on 32-bit platform results in:

/home/shade/jdk-jdk/build/linux-x86-normal-server-fastdebug/hotspot/variant-server/libjvm/objs/jfrStringPoolBuffer.o: In function `unsigned long long Atomic::FetchAndAdd<Atomic::PlatformAdd<8u> >::operator()<unsigned long long, unsigned long long>(unsigned long long, unsigned long long volatile*, atomic_memory_order) const': 
/home/shade/jdk-jdk/src/hotspot/share/runtime/atomic.hpp:670: undefined reference to `unsigned long long Atomic::PlatformAdd<8u>::fetch_and_add<unsigned long long, unsigned long long>(unsigned long long, unsigned long long volatile*, atomic_memory_order) const' 

This can be emulated with CAS-ed loop on most platforms.

This used to be controlled by SUPPORTS_CMPXCHG8 but that went with the Atomic class templatization - but AFAIKnew everything still worked fine for 32-bit x86 as it does support cmpxchg8. Where have things gone wrong ??

16-05-2018

Relates :	JDK-8203299 - StringPoolBuffer access covered by exclusive access invariant, remove (problematic) cas operations
Relates :	JDK-8203274 - 32-bit build failures after JDK-8199712 (Flight Recorder)