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

[Jaroslav Bachorík]

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.

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