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 shenandoah-dev
mailing list