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

[Roman Kennke]

>> 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?

Yes, I think we should do that, and also start working on backporting
JDK-8212611.

Roman