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