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

[Andrew Dinn]

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