[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