[8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing
Andrew Haley
aph at redhat.com
Wed Jun 10 09:38:46 UTC 2020
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
More information about the jdk8u-dev
mailing list