[8] RFR: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject

Roman Kennke rkennke at redhat.com
Tue Feb 25 20:02:14 UTC 2020


> This seems to be the cause of the problem that Kirill minimized [1].
> 
> In short, the LRB in CAS barrier slowpath was plugged in incorrectly. This caused the bug in the
> rare circumstances: evacuating the object that is in the middle of getAndSet'ing would still
> reference the "old" object on some paths. Most of the time it "works", because the object is left
> untouched.
> 
> Fix:
> 
> diff -r 9c948e9fa41e src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
> --- a/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp    Fri Dec 06 16:21:26 2019 -0500
> +++ b/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp    Tue Feb 25 20:53:24 2020 +0100
> @@ -1501,14 +1501,12 @@
>      }
>      __ xchg(LIR_OprFact::address(addr), dst, dst, LIR_OprFact::illegalOpr);
> 
>  #if INCLUDE_ALL_GCS
>      if (UseShenandoahGC && is_obj) {
> -      dst = ShenandoahBarrierSet::barrier_set()->bsc1()->load_reference_barrier(this, dst, NULL, true);
> -      LIR_Opr tmp = new_register(type);
> -      __ move(dst, tmp);
> -      dst = tmp;
> +      LIR_Opr tmp = ShenandoahBarrierSet::barrier_set()->bsc1()->load_reference_barrier(this, dst,
> NULL, true);
> +      __ move(tmp, dst);
>      }
>  #endif
> 
>      if (is_obj) {
>        // Seems to be a precise address
> 
> 
> Testing: hotspot_gc_shenandoah, Kirill's reproducer

Looks good! Thank you!

Roman



More information about the shenandoah-dev mailing list