RFR (11): [backport] 8221766: Load-reference barriers for Shenandoah

[Aleksey Shipilev]

On 5/31/19 4:23 PM, Roman Kennke wrote:
> This is the backport of load-reference-barriers to sh/jdk11. It goes on
> top of the recently proposed (and not-yet-pushed) CAS streamlining.
> 
> It is a tremendous harmonization in the C1 and C2 barriers sets: I
> basically copied over the relevant files from jdk/jdk at the point of
> the Load-ref-barriers-change, and retrofitted it to match jdk11.
> 
> I have *not* yet backported the LRB-related-bugfixes, yet. Let's start
> review on this here, while I'll pile on the followup-bugfixes in the
> meantime.
> 
> I also went over the sh/jdk11 vs. upstream jdk11u diff and reverted any
> change that's not needed anymore (resolve() and equals() stuff for the
> most part). It is *much* nicer now. :-) Notably, it makes
> oopDesc::unsafe_equals() disappear, and we should do the equivalent in
> jdk/jdk to match it.

Yeah, and I have a bit of reservation about that, seeing the stuff that is changed. It is probably
fine to include in LRB backport, as it would be the jdk11u-specific (and later jdk8u-specific)
change later anyway.

> http://cr.openjdk.java.net/~rkennke/backport-jdk11-JDK-8221766/webrev.00/

First look:

*) src/hotspot/share/ci/ciObjectFactory.cpp
  I don't see sh/jdk11 change that needs to be reverted...

*) src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
  This is needed why? I don't see it used in Shenandoah code anywhere. There is a definition in
src/hotspot/share/gc/shared/c1/barrierSetC1.cpp, though.

  34 #ifndef PATCHED_ADDR
  35 #define PATCHED_ADDR  (max_jint)
  36 #endif

*) src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp
 This breaks Solaris. (also, see other enums?)

  47     ShenandoahNone,
  48   };

*) src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
 This thing looks like the accidental backport of pre-evac-ing all roots.

*) src/hotspot/share/opto/mulnode.cpp
 This does not seem related to LRB all that much. We'd need to see if matcher still matches
fastpaths right.


-- 
Thanks,
-Aleksey