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

[Andrew Haley]

On 10/06/2020 09:27, Jaroslav Bachorík wrote:
> On Tue, Jun 9, 2020 at 11:51 AM Andrew Haley <aph at redhat.com> wrote:
>>
>> On 08/06/2020 17:41, Jaroslav Bachorík wrote:
>>>> 2. What are the risks of including this patch?
>>>
>>> In general, changing the initialization order for java.lang.Class
>>> could cause problems for a code that would operate with assumption of
>>> the java.lang.Class not being initialized very early on in the JVM
>>> startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
>>> tests are still passing after adding this change
>>
>> On May 15 I asked for the early initialization of java.lang.class to
>> be made conditional on JFR being in use. It seems this has still not
>> been done, even in
>> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04.
> 
> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04/src/share/vm/runtime/thread.cpp.sdiff.html
> L3505-3508 is not sufficient?
> The JFR specific earlier initialization is guarded by if-block. Then,
> the original initialization block is at L3521-3524 and will be run if
> JFR is not enabled.

I'm looking at this:

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?

If this is not true, and the initialize_class only runs if JFR is
enabled, how does that work?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671