RFR: 8353067: Shenandoah: Re-shuffle GC state enum for better encoding

[William Kemper]

On Fri, 27 Feb 2026 00:31:59 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Currently, we have weird code generation in aarch64 Shenandoah barriers, e.g.:
> 
>   // Check for heap stability
>   if (is_strong) {
>     __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, heap_stable);
>   } else {
>     Label lrb;
>     __ tbnz(rscratch2, ShenandoahHeap::WEAK_ROOTS_BITPOS, lrb);
>     __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, heap_stable);
>     __ bind(lrb);
>   }
> 
> The double-test in the weak-path could be avoided by doing something like:
> 
>   __ andb(rscratch2, rscratch2, ShenandoahHeap::WEAK_ROOTS | ShenandoahHeap::HAS_FORWARDED);
>   __ cbz(done);
> 
> 
> However, the two constants together makes 17, and this can not be encoded as immediate in aarch64. Re-ordering the GC state enum such that the two constants are adjacent would likely solve this.
> 
> In this PR:
> * GC state enum has been re-shuffled to make HAS_FORWARDED and WEAK_ROOTS adjacent,
> * The assemble code is also updated  to leverage this to reduce instructions.
> 
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [ ] GHA

Changes requested by wkemper (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 300:

> 298: public:
> 299:   enum GCStateBitPos {
> 300:     // Heap has forwarded objects: needs LRB barriers.

Do we need a disclaimer comment here that warns that changing/reordering these could break barrier codegen on aarch64?

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

PR Review: https://git.openjdk.org/jdk/pull/29949#pullrequestreview-3864299812
PR Review Comment: https://git.openjdk.org/jdk/pull/29949#discussion_r2861981359