[8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing

[Jaroslav Bachorík]

On Wed, Jun 10, 2020 at 11:38 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 10/06/2020 09:27, Jaroslav Bachorík wrote:
> > On Tue, Jun 9, 2020 at 11:51 AM Andrew Haley <aph at redhat.com> wrote:
> >>
> >> On 08/06/2020 17:41, Jaroslav Bachorík wrote:
> >>>> 2. What are the risks of including this patch?
> >>>
> >>> In general, changing the initialization order for java.lang.Class
> >>> could cause problems for a code that would operate with assumption of
> >>> the java.lang.Class not being initialized very early on in the JVM
> >>> startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
> >>> tests are still passing after adding this change
> >>
> >> On May 15 I asked for the early initialization of java.lang.class to
> >> be made conditional on JFR being in use. It seems this has still not
> >> been done, even in
> >> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04.
> >
> > http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04/src/share/vm/runtime/thread.cpp.sdiff.html
> > L3505-3508 is not sufficient?
> > The JFR specific earlier initialization is guarded by if-block. Then,
> > the original initialization block is at L3521-3524 and will be run if
> > JFR is not enabled.
>
> I'm looking at this:
>
> 3505 #if INCLUDE_JFR
> 3506     // The VM creates & returns objects of this class. Make sure it's initialized.
> 3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
> 3508 #endif
>
> ISTM that this code is run unconditionally if INCLUDE_JFR is set at compile
> time. Am I misunderstanding something?

Ok. I misunderstood the original request. I thought it was supposed to
be in-line with other JFR specific changes which are guarded with
compile-time conditional blocks.

>
> If this is not true, and the initialize_class only runs if JFR is
> enabled, how does that work?

This thing you ask (runtime check for whether JFR is enabled) is
impossible at that place, AFAIK. The affected code is in 'create_vm'
block so JVM is not really alive. Checking the JFR enabled status
requires parsing JFR configs which happens to be done in Java and that
requires java.lang.Class to be already linked and initialized - making
it impossible to check the JFR enablement status before initializing
java.lang.Class.

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