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

[Roman Kennke]

Hi Zhengyu,

Thanks for reviewing.

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

Oops that is a mistake. It should just check !UseShenandoahGC on 32bit
too. Good catch.

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

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.


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