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

[Mario Torre]

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/