[11] RFR: Fix ShenandoahBarrierSetC2::enqueue_useful_gc_barrier (part of JDK-8212611)

[Aleksey Shipilev]

On 9/6/19 4:58 PM, Aleksey Shipilev wrote:
> There is a discrepancy between jdk/jdk and sh/jdk11 definition of BSC2::enqueue_useful_gc_barrier,
> where one thing adds the node to the IGVN worklist [1], and another adds all users to it [2]. It was
> introduced by JDK-8212611 [3], and we should consider backporting it to 11u.
> 
> Meanwhile, sh/jdk11 x86_32 CTW fails without that patch:
> 
> $ CONF=linux-x86-normal-server-fastdebug make run-test TEST_VM_OPTS="-XX:-TieredCompilation
> -XX:+UseShenandoahGC" TEST=applications/ctw/modules/jdk_scripting_nashorn.java
> 
> #
> #  Internal Error (/home/shade/trunks/shenandoah-jdk11/src/hotspot/share/opto/compile.cpp:2851),
> pid=23210, tid=23220
> #  assert(!ShenandoahBarrierSetC2::has_only_shenandoah_wb_pre_uses(addp)) failed: useless address
> computation?
> #

Seeing exactly the same failure in sh/jdk11.

> I believe the best course of action would be to pick up safer parts of JDK-8212611 to sh/jdk11:
>   https://cr.openjdk.java.net/~shade/shenandoah/11u-fix-bsc2-eugcb/webrev.01/

Eh. This got somehow reverted from sh/jdk11 during this merge:

 changeset:   53541:bc2d5a439bc2
 parent:      53359:743587c28e0f
 parent:      53540:ae7ed8c70ecc
 user:        shade
 date:        Wed Oct 30 12:24:36 2019 +0100
 summary:     Merge

The same webrev applies cleanly to sh/jdk11.

> Testing: {x86_64, x86_32} CTW tests, {x86_64, x86_32} hotspot_gc_shenandoah (running)

...and passes the same testing.

I am thinking to re-push this to sh/jdk11. The downside: it increases our upstream exposure until
JDK-8212611 and dependent issues are in 11u. Thoughts?

-- 
Thanks,
-Aleksey