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

[Aleksey Shipilev]

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

-- 
Thanks,
-Aleksey

[1] https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011509.html