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

[Jaroslav Bachorík]

Hi Mario,

On Wed, Jun 10, 2020 at 8:05 PM Mario Torre
<neugens.limasoftware at gmail.com> wrote:
>
> Jaroslav,
>
> Isn't the requirement here to prevent the segfault only to call
>
> Jfr::on_create_vm_2()
>
> After the java_lang_Class has been initialized?
>
> In that case we could avoid moving the initialisation around and only
> move the JvmtiExport block, I'm not sure I understand the startup
> sequence in full, but I think this is a lot safer than rearranging the
> init for java_lang_Class.

Yes, it looks pretty much like that. I am re-running all tests with
the java_lang_Class initialization being at the original place and so
far the results seem good.

As for why it was shuffled - it was mostly to mimic what happens in
JDK11 (https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/thread.cpp#l3508)

I am also almost sure I was getting errors related to java_lang_Class
not being linked from JFR tests at the time I was working on the
backport. But I don't see those errors now even when I put the
java_lang_Class initialization back.

>
> Cheers,
> Mario
>
> Il giorno mer 10 giu 2020 alle ore 19:52 Mario Torre
> <neugens.limasoftware at gmail.com> ha scritto:
> >
> > Andrew, Jaroslav,
> >
> > One thing I just realised is this change:
> >
> > 3494   // Always call even when there are not JVMTI environments yet,
> > since environments
> > 3495   // may be attached late and JVMTI must track phases of VM execution
> > 3496   JvmtiExport::enter_start_phase();
> > 3497
> > 3498   // Notify JVMTI agents that VM has started (JNI is up) - nop if
> > no agents.
> > 3499   JvmtiExport::post_vm_start();
> >
> > I think we want to keep this code earlier when JFR is not compiled in,
> > it should be ifdefed too, right now we move it unconditionally if I
> > read this right.

Ok, let me take a look at it.

-JB-

> >
> > Cheers,
> > Mario
> >
> > Il giorno mer 10 giu 2020 alle ore 18:56 Andrew Dinn
> > <adinn at redhat.com> ha scritto:
> > >
> > > On 10/06/2020 17:05, Mario Torre wrote:
> > > > Doesn’t that create an issue when JFR is not started but then enabled at
> > > > runtime via the agent?
> > >
> > > I don't know? Does it? You tell me.
> > >
> > > No one has yet explained why it is necessary to promote initialization
> > > of java_lang_Class before initialization of other classes when JFR is
> > > included in the build. Needless to say Andrew Haley is very wary of
> > > changing class init order in jdk8u because in the past doing so has
> > > caused subtle, nasty bugs.
> > >
> > > So, please explain to me: is there is a good reason why that class init
> > > re-ordering has to happen /whether or not/ FlightRecorder is enabled?
> > > Does initializing java_lang_Class before other classes have some side
> > > effect that makes JFR work correctly even when it is enabled later on?
> > >
> > > If so then I think that must mean that it changes the way that the init
> > > of the classes that were normally processed before java_lang_Class
> > > proceeds. In which case that means we really need to know what that side
> > > effect is in order to be sure it won't create any unnecessary risk.
> > >
> > > Is this perhaps to do with JFR redefining the bytecode for java_lang_Class?
> > >
> > > > Btw, this patch has been backported in 11 and 13 without this level of
> > > > discussion, I guess we should revisit those patches too at this point.
> > > Well yes, probably. Are you sure the same re-ordering was done as part
> > > of the 11 and 13 backports? Startup order does vary from one release to
> > > the next.
> > >
> > > regards,
> > >
> > >
> > > Andrew Dinn
> > > -----------
> > > Senior Principal Software Engineer
> > > Red Hat UK Ltd
> > > Registered in England and Wales under Company Registration No. 03798903
> > > Directors: Michael Cunningham, Michael ("Mike") O'Neill
> > >
> >
> >
> > --
> > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> > Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> >
> > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> > Proud GNU Classpath developer: http://www.classpath.org/
> > OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> >
> > Please, support open standards:
> > http://endsoftpatents.org/
>
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/