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

[Mario Torre]

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.

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