RFR(sh/jdk11): Refactor/isolate critical pinning

[Zhengyu Gu]

> 
> Well, it's exactly the point. Epsilon does *not* support critical-
> native object pinning in jdk11u, and we don't want to silently change
> behaviour of anything by introducing Shenandoah, and it must be very
> obviously isolated. The status-quo for Epsilon in jdk11u is preserved
> by this patch. If we consider it important, we can improve it later.

Actually, it does:

http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/c87a19aed831/src/hotspot/share/gc/epsilon/epsilonHeap.hpp#l125

Although, Epsilon pins nothing, but logically seems wrong.

-Zhengyu

> 
> 
> http://cr.openjdk.java.net/~rkennke/shjdk11-refactor-isolate-critical-pinning/webrev.01/
> 
> Ok now?
> 
> Thanks,
> Roman
> 
> 
>> ...
>>
>> -Zhengyu
>>
>>
>>
>>
>>
>> On 7/6/20 3:51 PM, Roman Kennke wrote:
>>> I'm running an effort to bring our upstream exposure vs jdk11u to
>>> (near) zero.
>>>
>>> Critical pinning support touches a few places in x86 assembly which
>>> are
>>> rather hairy, and should look much better when isolated such that
>>> builds without Shenandoah more obviously generate the same code as
>>> jdk11u upstream currently does.
>>>
>>> It moves the new method definitions to Shenandoah-files. It trades
>>> cleaner sharde code at the expense of slightly increased mess in
>>> Shenandoah files (I copied some helper methods there, seems
>>> harmless to
>>> me). The new inline code parts are now guarded with #if
>>> INCLUDE_SHENANDOAHGC and if (UseShenandoahGC) so are obviously
>>> guaranteed to not leak out into non-Shenandoah code.
>>>
>>> Webrev:
>>> http://cr.openjdk.
>>> java.net/~rkennke/shjdk11-refactor-isolate-critical-
>>> pinning/webrev.00/
>>>
>>> Testing: hotspot_gc_shenandoah (x86_32, x86_64, builds with and
>>> without
>>> Shenandoah)
>>>
>>> Ok?
>>>
>>> Roman
>>>
>