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