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

[Aleksey Shipilev]

On 3/3/20 7:37 PM, Roman Kennke wrote:
>>> 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.

Right. That's good.

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

Since filtering NULL there is harmless now (and may stop being harmless in future, *if* we ever
decide to backport native stuff), I believe having that null check there is the best course of action.

Looks good.

-- 
Thanks,
-Aleksey