RFR (S): 8203274: 32-bit build failures after JDK-8199712 (Flight Recorder)

[David Holmes]

On 16/05/2018 7:08 PM, Aleksey Shipilev wrote:
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8203274
> 
> Testing: x86_64 build, x86_32 build, arm32-hflt build
> 
> Fix:
> 
> diff -r 2e886b7b3d72 -r a7c343a2f1c4 src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp
> --- a/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp	Wed May 16 09:58:24 2018 +0200
> +++ b/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp	Wed May 16 11:00:04 2018 +0200
> @@ -1232,7 +1232,7 @@
>     // This means the original constant pool contents are copied unmodified
>     writer.bytes(orig_stream->buffer(), orig_access_flag_offset);
>     assert(writer.is_valid(), "invariant");
> -  assert(writer.current_offset() == orig_access_flag_offset, "invariant"); // same positions
> +  assert(writer.current_offset() == (intptr_t)orig_access_flag_offset, "invariant"); // same positions
>     // Our writer now sits just after the last original constant pool entry.
>     // I.e. we are in a good position to append new constant pool entries
>     // This array will contain the resolved indexes
> diff -r 2e886b7b3d72 -r a7c343a2f1c4 src/hotspot/share/jfr/recorder/stringpool/jfrStringPoolBuffer.cpp
> --- a/src/hotspot/share/jfr/recorder/stringpool/jfrStringPoolBuffer.cpp	Wed May 16 09:58:24 2018 +0200
> +++ b/src/hotspot/share/jfr/recorder/stringpool/jfrStringPoolBuffer.cpp	Wed May 16 11:00:04 2018 +0200
> @@ -55,7 +55,17 @@
>   }
> 
>   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.

I'm somewhat annoyed about this. I thought after the templatization of 
Atomic everything was still setup to correctly handle the fallback to 
using CAS for 64-bit Atomic ops on 32-bit, for x86 at least.

David

> +  uint64_t cur, val;
> +  do {
> +     cur = Atomic::load(&_string_count_top);
> +     val = cur + value;
> +  } while (Atomic::cmpxchg(val, &_string_count_pos, cur) != cur);
> +#endif
>   }
> 
>   void JfrStringPoolBuffer::set_string_top(uint64_t value) {
> diff -r 2e886b7b3d72 -r a7c343a2f1c4 src/hotspot/share/jfr/utilities/jfrAllocation.cpp
> --- a/src/hotspot/share/jfr/utilities/jfrAllocation.cpp	Wed May 16 09:58:24 2018 +0200
> +++ b/src/hotspot/share/jfr/utilities/jfrAllocation.cpp	Wed May 16 11:00:04 2018 +0200
> @@ -66,8 +66,8 @@
>       const size_t total_deallocated = atomic_add_jlong(dealloc_size, &_deallocated_bytes);
>       const size_t current_live_set = atomic_add_jlong(dealloc_size * -1, &_live_set_bytes);
>       log_trace(jfr, system)("Deallocation: [" SIZE_FORMAT "] bytes", dealloc_size);
> -    log_trace(jfr, system)("Total dealloc [" JLONG_FORMAT "] bytes", total_deallocated);
> -    log_trace(jfr, system)("Liveset:      [" JLONG_FORMAT "] bytes", current_live_set);
> +    log_trace(jfr, system)("Total dealloc [" SIZE_FORMAT "] bytes", total_deallocated);
> +    log_trace(jfr, system)("Liveset:      [" SIZE_FORMAT "] bytes", current_live_set);
>     }
>   }
> 
> 
> Thanks,
> -Aleksey
> 
>