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

[Zhengyu Gu]

okay.

-Zhengyu


On 7/7/20 3:27 PM, Roman Kennke wrote:
> 
>>> 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.
> 
> Well yes, as I said, that is the status quo, and *we are not going to
> change that* at least not silently with the big Shenandoah upstreaming?
> 
> http://cr.openjdk.java.net/~rkennke/shjdk11-refactor-isolate-critical-pinning/webrev.01/
> 
> Ok to push that?
> 
> Roman
> 
> 
>> -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
>>>>>
>