RFR (sh/8): Backport: JDK-8222766: Shenandoah: streamline post-LRB CAS barrier (x86)

[Aleksey Shipilev]

On 2/21/20 9:44 PM, Roman Kennke wrote:
> Unfortunately, our new cas-obj assembly doesn't always exit with
> condition flags intact. But we *do* have code to fill the result
> register. So we should use that. The C1 adjustments pass the result
> register to the CAS instruction and use that directly and skip emitting
> the trailing cmove in IR.

Ha. So this was the testing culprit?

 797       __ cas_obj(addr, cmp.result(), val.result(), new_register(T_OBJECT),
new_register(T_OBJECT), result);
 798       return; <--- ouch

Suggestion:

  __ cas_obj(addr, cmp.result(), val.result(), new_register(T_OBJECT), new_register(T_OBJECT), result);
  // Shenandoah C1 barrier would do all result management itself, shortcut here.
  return;


> Testing: hotspot_gc_shenandoah passes
> Might be useful if Aleksey or somebody else could run this on 32bit. My
> own 32bit setup seems broken ATM.

My cross-compilation setup is also a bit broken, so two native tests cannot compile and run:
 FAILED: gc/shenandoah/jni/TestCriticalNativeArgs.sh
 FAILED: gc/shenandoah/jni/TestCriticalNativeStress.sh

This is not caused by the patch, and I don't believe those tests would be affected anyway.

> http://cr.openjdk.java.net/~rkennke/JDK-8222766-jdk8/webrev.00/

The shenandoahBarrierSetAssembler_x86.cpp change was transplated as is, right? I did not spot
substantial differences against jdk/jdk, except minor changes around gc_state access and mark word
constants.

Looks good.

-- 
Thanks,
-Aleksey