RFR (XS) 8232778: Shenandoah: SBSA::arraycopy_prologue checks wrong register

Aleksey Shipilev shade at redhat.com
Tue Oct 22 12:12:24 UTC 2019


Thanks, I also think it is trivial. Pushed.

-Aleksey

On 10/22/19 2:04 PM, Roman Kennke wrote:
> Good spot!
> 
> Looks good, thanks!
> Roman
> 
>> Bug:
>>   https://bugs.openjdk.java.net/browse/JDK-8232778
>>
>> Fix:
>>
>> diff -r 24d411cb3a90 src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
>> --- a/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp   Tue Oct 22
>> 08:57:41 2019 +0200
>> +++ b/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp   Tue Oct 22
>> 13:39:05 2019 +0200
>> @@ -58,7 +58,7 @@
>>        Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset()));
>>        __ ldrb(rscratch1, gc_state);
>>        if (dest_uninitialized) {
>> -        __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done);
>> +        __ tbz(rscratch1, ShenandoahHeap::HAS_FORWARDED_BITPOS, done);
>>        } else {
>>          __ mov(rscratch2, ShenandoahHeap::HAS_FORWARDED | ShenandoahHeap::MARKING);
>>          __ tst(rscratch1, rscratch2);
>>
>> The load happens into rscratch1, yet we are testing rscratch2. I think this silently breaks
>> arraycopy to-space guarantees, as rscratch2 may contain garbage.
>>
>> Testing: aarch64 hotspot_gc_shenandoah
>>
> 


-- 
Thanks,
-Aleksey




More information about the hotspot-gc-dev mailing list