RFR: (sh/jdk11): Bulk backports 2020-03-03

[Roman Kennke]

>> Changesets:
>> http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-03-03/changesets.txt
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-03-03/webrev.00/
> 
> *) I don't understand the move in shenandoahBarrierSet.cpp -- does it correct the method placement
> to its location in 8233339?

The methods have been there before, come in via another backport. This
backport should have carried it instead. This change puts them in the
same place where they are in jdk/jdk for consistency.

> *) Do we really need 8238574? Notice in the original changeset it checks the result of LRB_native:
>   https://hg.openjdk.java.net/jdk/jdk/rev/8d8916159b62
>  ...is it even possible with non-native LRB in 11u?

This is a bit strange. It *is* the native (runtime) barrier in sh/11.
However, it's pretty useless because we don't do any concurrent roots
processing. No, I don't think the NULL can actually happen because we
process all roots at the pause. What should I do? Get rid of the change?
Get rid of the whole runtime native barriers?

Roman