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

Mario Torre neugens.limasoftware at gmail.com
Wed Jun 10 16:05:55 UTC 2020


Doesn’t that create an issue when JFR is not started but then enabled at
runtime via the agent?

So far the only use case for this was attaching via JMX but an agent could
still request JFR, I’m not sure if creating a recording in pre-main is a
legal use case or not though.

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.

Cheers,
Mario

On Wed 10. Jun 2020 at 17:48, Andrew Dinn <adinn at redhat.com> wrote:

> On 10/06/2020 13:31, Jaroslav Bachorík wrote:
> >> 3505 #if INCLUDE_JFR
> >> 3506     // The VM creates & returns objects of this class. Make sure
> it's initialized.
> >> 3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
> >> 3508 #endif
> >>
> >> ISTM that this code is run unconditionally if INCLUDE_JFR is set at
> compile
> >> time. Am I misunderstanding something?
> >
> > Ok. I misunderstood the original request. I thought it was supposed to
> > be in-line with other JFR specific changes which are guarded with
> > compile-time conditional blocks.
> >
> >>
> >> If this is not true, and the initialize_class only runs if JFR is
> >> enabled, how does that work?
> >
> > This thing you ask (runtime check for whether JFR is enabled) is
> > impossible at that place, AFAIK. The affected code is in 'create_vm'
> > block so JVM is not really alive. Checking the JFR enabled status
> > requires parsing JFR configs which happens to be done in Java and that
> > requires java.lang.Class to be already linked and initialized - making
> > it impossible to check the JFR enablement status before initializing
> > java.lang.Class.
> How is that so? I believe command line arguments will have been
> processed at this stage. If so then you can easily detect whether or not
> JFR has been enabled on the command line. The simplest thing is to check
> global boolean FlightRecorder. This global is set from the command line
> using -X:+FlightRecorder and cleared using -X:-FlightRecorder. If not
> specified it defaults to false.
>
> So, in the case where JFR is conditionally compiled in you can call
> initialize_class() early if FlightRecorder is true and call it at the
> normal point of FlightRecorder is false.
>
> In the case where JFR is conditionally compiled out then the call should
> happen late as happened before this patch.
>
> Is there any reason why that won't work?
>
> 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/


More information about the jdk8u-dev mailing list