RFR (sh/jdk11): Relax Shenandoah/C2 verifier against JDK11 shortcomings

[Roman Kennke]

With backport of JDK-8228775 in place, the fix amounts to:

http://cr.openjdk.java.net/~rkennke/jdk11-c2-verifier-fixes/webrev.03/

This is truly jdk11-specific, because in jdk13/14 we do actually have
barriers on mirror-loads (mostly to support concurrent class unloading).

Testing: hotspot_gc_shenandoah and the failing nightly test with
+ShenandoahVerifyOptoBarriers

Ok?

Roman

> We determined (on IRC) that the check for null-inputs doesn't do
> anything useful in post-LRB-world: there are no barriers directly
> feeding into intrinsics, and therefore doesn't make a difference whether
> or not the input comes as not-null-type or not. Let's remove the test in
> sh/jdk11 to make nightlies happy, and also in -dev:
> 
> updated webrev:
> http://cr.openjdk.java.net/~rkennke/jdk11-c2-verifier-fixes/webrev.01/
> 
> Bug for -dev:
> https://bugs.openjdk.java.net/browse/JDK-8228775
> 
> or we can fix it in jdk/jdk real quick first, then cherry-pick it to
> sh/11. What do you think?
> 
> Roman
> 
>> On 7/30/19 12:28 AM, Roman Kennke wrote:
>>> - A couple of intrinsics are a bit careless and don't check+cast their
>>> inputs to not-null. Our verifier doesn't like. Let's special-case them
>>> and silence the verifier. (We might want to fix the cases via jdk11u
>>> properly.)
>>
>> I understand this is missing in 11u?
>>  https://bugs.openjdk.java.net/browse/JDK-8209684
>>
>>> http://cr.openjdk.java.net/~rkennke/jdk11-c2-verifier-fixes/webrev.00/
>>
>> Please put "TODO:" in the comments, and maybe reference the bug above?
>>
>