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

Roman Kennke rkennke at redhat.com
Mon Jun 3 10:23:27 UTC 2019


Hi Aleksey,

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

Fixed.

> *) 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

Filed: https://bugs.openjdk.java.net/browse/JDK-8225171

> *) src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp
>  This breaks Solaris. (also, see other enums?)
> 
>   47     ShenandoahNone,
>   48   };

Fixed. I only found this one instance of the problem.

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

As explained earlier, this was needed to get it to work correctly at
all, because of different/missing non-heap-barriers. AFAICT, this is as
close as possible to original LRB patch.

> *) 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.

Yup. Reverted and adapted to LRB.

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

(give it a few minutes...)

Roman



More information about the shenandoah-dev mailing list