[8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing
Jaroslav Bachorík
jaroslav.bachorik at datadoghq.com
Wed May 20 21:30:19 UTC 2020
On Fri, May 15, 2020 at 5:53 PM Jaroslav Bachorík
<jaroslav.bachorik at datadoghq.com> wrote:
>
> Hi Andrew,
>
> On Fri, May 15, 2020 at 3:35 PM Andrew Haley <aph at redhat.com> wrote:
> >
> > On 5/15/20 1:01 PM, Mario Torre wrote:
> > > The patch is good to go for my side, we still need to wait for the
> > > maintainer to change the status to jdk8u-fix-yes before you can push
> > > though.
> >
> > I'm tempted to say yes. However, I get frightened whenever I see any
> > change to HotSpot initialization code, particularly things that change
> > the order in which classes are initialized. Can you make the early
> > call to initialize_class(vmSymbols::java_lang_Class()) JFR-only?
>
> I can try that. Let me get back with the result.
I put the early java_lang_Class initialization in `#if INCLUDE_JFR`
block. The original java_lang_Class initialization location was
enclosed in an inverted `#if INCLUDE_JFR` block to ensure the original
behaviour if JFR is not enabled in build config.
Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.02/
Thanks,
-JB-
>
> -JB-
>
> >
> > --
> > Andrew Haley (he/him)
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > https://keybase.io/andrewhaley
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >
More information about the jdk8u-dev
mailing list