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

[Zhengyu Gu]

Hi Roman,

sharedRuntime_x86_32.cpp/sharedRuntime_x86_64.cpp

1846   if (is_critical_native SHENANDOAHGC_ONLY(&& 
!Universe::heap()->supports_object_pinning())) {

why they are different  (32 vs. 64)?

This refactor is awkward, since Epsilon also support object pinning ...

-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
>