RFR: 8326936: RISC-V: Shenandoah GC crashes due to incorrect atomic memory operations

[MaxXing]

With compressed oops enabled, Shenandoah GC crashes in the concurrent marking phase due to some incorrect atomic memory operations. This resulted in the failure of multiple related tests, including `gc/shenandoah/TestSmallHeap.java`, `gc/metaspace/TestMetaspacePerfCounters.java#Shenandoah-64`, and so on, tested on XuanTie C910 and QEMU.

This failure is related to a GCC bug we recently discovered: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130.

In detail, there's a pattern in method `ShenandoahHeap::conc_update_with_forwarded`:


if (in_collection_set(obj)) {
  // Dereferences `obj` without explicit null check.
  oop fwd = ShenandoahBarrierSet::resolve_forwarded_not_null(obj);
  // Then calls atomic built-in.
  atomic_update_oop(fwd, p, obj);
}


`atomic_update_oop` then compresses `obj` into a 32-bit word and calls the built-in `__atomic_compare_exchange`. The latter produces incorrect assembly that comparing this unsigned 32-bit word with the sign-extended result of `lr.w` instructions.

This bug can be bypassed by adding an explicit null check (like `if (obj && in_collection_set(obj))`), or adding compiler flag `-fno-delete-null-pointer-checks`.

In previous commits, JDK-8316186 removed RISC-V's `PlatformCmpxchg<4>` but left the flag `-fno-delete-null-pointer-checks` enabled. Then JDK-8316893 removed the flag and made the bug visible. This patch adds `PlatformCmpxchg<4>` back.

-------------

Commit messages:
 - Fix a bug about GCC atomic built-in function.

Changes: https://git.openjdk.org/jdk/pull/18039/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18039&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326936
  Stats: 44 lines in 1 file changed: 43 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18039/head:pull/18039

PR: https://git.openjdk.org/jdk/pull/18039