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

Roman Kennke rkennke at redhat.com
Tue Oct 22 12:04:37 UTC 2019


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
> 




More information about the hotspot-gc-dev mailing list