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

[Xiaolong Peng]

On Fri, 27 Feb 2026 00:47:53 GMT, William Kemper <wkemper 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
>
> 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?

Asked Kiro to added it, it looks fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29949#discussion_r2862048473