RFR(sh/jdk11): Refactor/isolate critical pinning
Roman Kennke
rkennke at redhat.com
Tue Jul 7 19:27:13 UTC 2020
> > 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
> > > >
More information about the shenandoah-dev
mailing list