RFR (sh/jdk11): C2: Always emit arraycopy barriers for Shenandoah
Aleksey Shipilev
shade at redhat.com
Sun Jul 28 10:28:28 UTC 2019
On 7/26/19 10:28 PM, Roman Kennke wrote:
> Builds for shenandoah/jdk11 are currently failing. It looks like we are
> not (always) emitting arraycopy barriers. This started happening with
> LRB backports, and is presumably caused by GC interface difference
> between jdk13/14 and jdk11 there.
>
> The quick fix is:
> diff --git
> a/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> @@ -748,7 +748,7 @@
> }
>
> bool ShenandoahBarrierSetC2::array_copy_requires_gc_barriers(BasicType
> type) const {
> - return false;
> + return type == T_OBJECT || type == T_ARRAY;
> }
>
> bool ShenandoahBarrierSetC2::clone_needs_postbarrier(ArrayCopyNode *ac,
> PhaseIterGVN& igvn) {
>
> It probably warrants some deeper investigation too, to ensure we're not
> over-doing it now. I seem to remember this was a bit peculiar. But let's
> fix the builds and do the correct thing first. Ok?
Yes, looks good.
ShenandoahBarrierSetC2::array_copy_requires_gc_barriers in jdk/jdk is significantly different, but
it would normally return "true" for T_OBJECT/T_ARRAY parts
--
Thanks,
-Aleksey
More information about the shenandoah-dev
mailing list