JDK-8203299 : StringPoolBuffer access covered by exclusive access invariant, remove (problematic) cas operations
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-05-16
  • Updated: 2019-06-20
  • Resolved: 2018-06-22
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 11 JDK 12
11 b20Fixed 12Fixed
Related Reports
Relates :  
JDK-8203274 - 32-bit build failures after JDK-8199712 (Flight Recorder)
Relates :  
JDK-8203283 - Provide 8-byte Atomic::add fallback for 32-bit platforms
Relates :  
JDK-8199712 - Flight Recorder
Comments
As part of integration for JDK-8199712, building and testing 32-bit platforms (see JDK-8203274) yielded: " 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' " for the expression: void JfrStringPoolBuffer::increment(uint64_t value) { Atomic::add(value, &_string_count_pos); } Part of fixing JDK-8203274, the following workaround was introduced:: void JfrStringPoolBuffer::increment(uint64_t value) { #if !(defined(ARM) || defined(IA32)) Atomic::add(value, &_string_count_pos); #else // TODO: This should be fixed in Atomic::add handling for 32-bit platforms, // see JDK-8203283. We workaround the absence of support right here. uint64_t cur, val; do { cur = Atomic::load(&_string_count_top); val = cur + value; } while (Atomic::cmpxchg(val, &_string_count_pos, cur) != cur); #endif } Now, we don't really need the atomic operations implemented via the CAS in the StringPoolBuffer. Because of the non-atomic behaviour of having to store both the updated byte position and the string count, there is already an exclusive mechanism in place. We can simplify this section and also remove the cas-loop workaround for 32-bits.
16-05-2018