8384605: [25u] backout Shenandoah backports causing failures

[GoeLin]

Undo shenandoah backports after last succesful nightly test.

We see tests failing on ppc:

on may 10th:
gc/shenandoah/TestAllocObjectArrays.java#no-tlab
gc/shenandoah/TestAllocObjects.java#static
on may 9th:
gc/shenandoah/TestAllocIntArrays.java#aggressive
gc/shenandoah/TestAllocObjectArrays.java#adaptive
gc/shenandoah/TestAllocObjectArrays.java#aggressive
gc/shenandoah/TestResizeTLAB.java#adaptive
on may 8th
gc/shenandoah/TestResizeTLAB.java#aggressive

gc/shenandoah/TestAllocObjectArrays.java#no-tlab failed around end of Novermber 2025 in jdk26, too.
Our test database points to https://bugs.openjdk.org/browse/JDK-8372542 which we obviously opened for this issue.
You might want to check whether a backport of this issue helps.

The crash on May 8th shows the following in hs_err:

# Internal Error ([.../openjdk-25u-dev-linux_ppc64le-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp:624], pid=4070744, tid=4070893
# assert(capacity > 0) failed: free regions must have allocation capacity

Stack: [0x00007ffe898b0000,0x00007ffe89ab0000], sp=0x00007ffe89aad030, free space=2036k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x1b14a00] ShenandoahRegionPartitions::assert_bounds()+0x750 (shenandoahFreeSet.cpp:624)
V [libjvm.so+0x1b165fc] ShenandoahFreeSet::allocate_contiguous(ShenandoahAllocRequest&, bool)+0x75c (shenandoahFreeSet.cpp:1292)
V [libjvm.so+0x1ba084c] ShenandoahHeap::allocate_memory_under_lock(ShenandoahAllocRequest&, bool&)+0x7c (shenandoahHeap.cpp:1085)
V [libjvm.so+0x1baa41c] ShenandoahHeap::allocate_memory(ShenandoahAllocRequest&)+0x13c (shenandoahHeap.cpp:980)
V [libjvm.so+0x1baad0c] ShenandoahHeap::mem_allocate(unsigned long, bool*)+0x4c (shenandoahHeap.cpp:1119)
V [libjvm.so+0x164fe80] MemAllocator::mem_allocate(MemAllocator::Allocation&) const+0x120 (memAllocator.cpp:241)
V [libjvm.so+0x1650048] MemAllocator::allocate() const+0xc8 (memAllocator.cpp:358)
V [libjvm.so+0x1efd31c] TypeArrayKlass::allocate_common(int, bool, JavaThread*)+0x1ec (collectedHeap.inline.hpp:41)
V [libjvm.so+0x1803448] oopFactory::new_typeArray(BasicType, int, JavaThread*)+0x58 (typeArrayKlass.hpp:70)
V [libjvm.so+0x1057448] InterpreterRuntime::newarray(JavaThread*, BasicType, int)+0xf8 (interpreterRuntime.cpp:230)
j TestResizeTLAB.main([Ljava/lang/String;)V+38
j java.lang.invoke.LambdaForm$DMH+0x0000019f01041000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@25.0.4-internal
j java.lang.invoke.LambdaForm$MH+0x0000019f01042400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base@25.0.4-internal
j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base@25.0.4-internal
j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@25.0.4-internal
j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@25.0.4-internal
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@25.0.4-internal
j com.sun.javatest.regtest.agent.MainWrapper$MainTask.run()V+134
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@25.0.4-internal
j java.lang.Thread.run()V+19 java.base@25.0.4-internal
v ~StubRoutines::call_stub 0x00007fff6ba0085c
V [libjvm.so+0x10897cc] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x55c (javaCalls.cpp:415)
V [libjvm.so+0x183c3cc] os::os_exception_wrapper(void ()(JavaValue, methodHandle const&, JavaCallArguments*, JavaThread*), JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x3c (os_linux.cpp:5040)
V [libjvm.so+0x1089efc] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x36c (javaCalls.cpp:323)
V [libjvm.so+0x108a5d8] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0xd8 (javaCalls.cpp:185)
V [libjvm.so+0x12c8668] thread_entry(JavaThread*, JavaThread*)+0x108 (jvm.cpp:2761)
V [libjvm.so+0x10e82fc] JavaThread::thread_main_inner()+0x17c (javaThread.cpp:774)
V [libjvm.so+0x1e8db30] Thread::call_run()+0xe0 (thread.cpp:243)
V [libjvm.so+0x1840498] thread_native_entry(Thread*)+0x178 (os_linux.cpp:899)
C [libpthread-2.28.so+0x96a8] start_thread+0xf8
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j TestResizeTLAB.main([Ljava/lang/String;)V+38
j java.lang.invoke.LambdaForm$DMH+0x0000019f01041000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@25.0.4-internal
j java.lang.invoke.LambdaForm$MH+0x0000019f01042400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base@25.0.4-internal
j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base@25.0.4-internal
j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@25.0.4-internal
j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@25.0.4-internal
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@25.0.4-internal
j com.sun.javatest.regtest.agent.MainWrapper$MainTask.run()V+134
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@25.0.4-internal
j java.lang.Thread.run()V+19 java.base@25.0.4-internal

This buldk-revert undoes the following changes, all of which only touch gc/shenandoah
files (and a test).

https://bugs.openjdk.org/browse/JDK-8381382: Shenandoah: assert(capacity > 0) failed: free regions must have allocation capacity
https://bugs.openjdk.org/browse/JDK-8353115: GenShen: mixed evacuation candidate regions need accurate live_data
https://bugs.openjdk.org/browse/JDK-8382295: Shenandoah: wrong denominator in full gc summary
https://bugs.openjdk.org/browse/JDK-8380846: GenShen: Remove the experimental option to disable adaptive tenuring
https://bugs.openjdk.org/browse/JDK-8367646: [GenShen] Control thread may overwrite gc cancellation cause set by mutator
https://bugs.openjdk.org/browse/JDK-8381871: GenShen: ShenandoahGCHeuristics flag not reset after ignoring non-adaptive value
https://bugs.openjdk.org/browse/JDK-8374449: Shenandoah: Leaf locks used by Shenandoah need lower ranks
https://bugs.openjdk.org/browse/JDK-8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate
https://bugs.openjdk.org/browse/JDK-8365792: GenShen: assertion "Generations aren't reconciled"
https://bugs.openjdk.org/browse/JDK-8380431: Shenandoah: Concurrent modification of stack-chunk objects during evacuation
https://bugs.openjdk.org/browse/JDK-8373714: Shenandoah: Register heuristic penalties following a degenerated GC
https://bugs.openjdk.org/browse/JDK-8383183: Shenandoah: Mangle trashed regions up to top instead of end

Experiments showed that either 8373714 or 8383183 broke PPC, and JDK-8381382 fixes this. But 8381382 does not build on linux aarch:

• For target hotspot_variant-server_libjvm_objs_shenandoahGenerationalHeap.o:
  In file included from .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/runtime/atomic.hpp:862,
  from .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/oops/oop.hpp:35,
  from .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/gc/shared/ageTable.hpp:30,
  from .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp:28,
  from .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp:26:
  In member function 'T Atomic::PlatformOrderedLoad<byte_size, X_ACQUIRE>::operator()(const volatile T*) const [with T = unsigned int; long unsigned int byte_size = 4]',
  inlined from 'T Atomic::LoadImpl<T, PlatformOp, typename std::enable_if<PrimitiveConversions::Translate::value, void>::type>::operator()(const volatile T*) const [with T = ShenandoahHeapRegion::RegionState; PlatformOp = Atomic::PlatformOrderedLoad<4, X_ACQUIRE>]' at .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/runtime/atomic.hpp:537:34,
  inlined from 'static T Atomic::load_acquire(const volatile T*) [with T = ShenandoahHeapRegion::RegionState]' at .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/runtime/atomic.hpp:887:67,
  inlined from 'ShenandoahHeapRegion::RegionState ShenandoahHeapRegion::state() const' at .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp:220:71,
  inlined from 'bool ShenandoahHeapRegion::is_active() const' at .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp:205:66,
  inlined from 'void ShenandoahGenerationalUpdateHeapRefsTask::update_references_in_remembered_set(uint, T&, const ShenandoahMarkingContext*, bool) [with T = ShenandoahConcUpdateRefsClosure; bool CONCURRENT = true]' at .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp:880:23:
  .../openjdk-25u-dev-linux_aarch64-dbg/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:203:66: error: 'unsigned int __atomic_load_4(const volatile void*, int)' writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
  203 | T operator()(const volatile T* p) const { T data; __atomic_load(const_cast<T*>(p), &data, __ATOMIC_ACQUIRE); return data; }
  | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  In member function 'void ShenandoahGenerationalUpdateHeapRefsTask::update_references_in_remembered_set(uint, T&, const ShenandoahMarkingContext*, bool) [with T = ShenandoahConcUpdateRefsClosure; bool CONCURRENT = true]':

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8384605 needs maintainer approval

Issue

• JDK-8384605: [25u] backout Shenandoah backports causing failures (Bug - P4 - Requested)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk25u-dev.git pull/560/head:pull/560
$ git checkout pull/560

Update a local copy of the PR:
$ git checkout pull/560
$ git pull https://git.openjdk.org/jdk25u-dev.git pull/560/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 560

View PR using the GUI difftool:
$ git pr show -t 560

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk25u-dev/pull/560.diff

[bridgekeeper]

👋 Welcome back goetz! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[earthling-amzn]

@GoeLin - This PR disables the warning for gcc that causes the build failure you reported. This is a known issue with gcc14 on aarch64.

[earthling-amzn]

/approval request This change disables the stringop-overflow for shenandoahGenerationalHeap.cpp which causes problems for gcc14 on aarch64.

[openjdk]

@earthling-amzn Only the author (@GoeLin) is allowed to issue the /approval command.