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

[Andrey Petushkov]

Just in case, starting a recording in pre-main works flawlessly with the
current state of the code (in fact AFAICT recording which is started via
command line is in fact started earlier than agent's premain is executed)

And yes, it's typical use-case that that JFR is not activated on the
command line but some time later the recording is requested with
jcmd/JMC/JMX. In this it's enabled via management

Andrey

On 10.06.2020 19:05, Mario Torre wrote:
> 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/