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