Fix jdk.jfr module resolution for JFR V2 startup and jcmd

[tomal-majumder]

JFR V2 (gated behind -XX:+EnableOpenJ9ExperimentalFlightRecording
on JDK17) assumed jdk.jfr was always resolved before touching any
of its classes. That breaks for a --module launch whose module
declares no "requires jdk.jfr", and for a jcmd JFR.start with no
-XX:StartFlightRecording on the command line. Both exercised by
test/jdk/jdk/jfr/jvm/TestModularImage.java, which failed several
ways: the "Started recording" print was silently dropped, a native
assertion crashed the VM when jdk.jfr was not resolved already
(e.g. --add-mods jdk.jfr not given at launch), and a module-resolution
failure printed the wrong text.

This introduces the following changes:

• Default LogTag.JFR_START to INFO instead of WARN, and tag the
  startup banner with it (was tagged as plain LogTag.JFR), so it
  is no longer filtered by the default logging threshold.

• Inject jdk.jfr into the root module set at boot when
  -XX:StartFlightRecording is given with JFR V2 enabled, via a
  synthesized jdk.module.addmods.<n> property. Extracted the
  shared injection logic into one addRequiredModuleProperty()
  helper, reused by two other existing call sites.

• Add ensureJfrModuleAvailable(): for jcmd with no
  -XX:StartFlightRecording on the command line, checks the boot
  layer, then loads jdk.jfr on demand since nothing requested it
  at startup. JFR internal structures now only initialize on
  success, removing a native assertion crash. jcmd DCmd entry
  points check this and return a clean error instead of failing
  in reflection.

• Print a leading error line in ClassLoader.java's module
  bootstrap catch block, matching the boot-layer error text
  TestModularImage.java expects.

Fixes: #23708

[JasonFengJ9]

which failed several
ways: the "Started recording" print was silently dropped, a native
assertion crashed the VM when jdk.jfr was not resolved already
(e.g. --add-mods jdk.jfr not given at launch), and a module-resolution
failure printed the wrong text.

Can you provide more details about the failure or the assertion, or is there any issue reference?

jcmd send/receive AttachAPI commands to a target process which has to run with -XX:+EnableOpenJ9ExperimentalFlightRecording to enable JFR V2 support.
However there is no need for jcmd to do actual JFR operations, if so, the dependence should be removed.

[tomal-majumder]

which failed several
ways: the "Started recording" print was silently dropped, a native
assertion crashed the VM when jdk.jfr was not resolved already
(e.g. --add-mods jdk.jfr not given at launch), and a module-resolution
failure printed the wrong text.

Can you provide more details about the failure or the assertion, or is there any issue reference?

jcmd send/receive AttachAPI commands to a target process which has to run with -XX:+EnableOpenJ9ExperimentalFlightRecording to enable JFR V2 support. However there is no need for jcmd to do actual JFR operations, if so, the dependence should be removed.

On the assertion / failure details:
The crash is in jfrInitializeInternalStructures() (runtime/vm/jfr.cpp). No separate tracking issue for this one. This PR covers it.

TestModularImage builds a jlinked image containing hello.world + jdk.jfr (Calls it with-jfr) and launches it with --module hello.world/hello.Main. hello.world's module-info has no requires jdk.jfr. The main issue is: a --module hello.world/hello.Main launch takes only the named module plus what it requires as the root set. jdk.jfr is pulled in only if some root requires it or --add-modules jdk.jfr is passed. Neither applies here, so even if jdk.jfr is in the image but never gets resolved into the boot layer.

So, with -XX:+EnableOpenJ9ExperimentalFlightRecording -XX:StartFlightRecording flags on, JFR V2 startup triggers JFRHelpers's static initializer, which (V2 enabled) calls VM.initializeInternalJFRStructures() → jfrInitializeInternalStructures() in runtime/vm/jfr.cpp:

...
jfrEventClass = internalFindClassUTF8(currentThread, "**jdk/jfr/Event**", ..., vm->systemClassLoader, 0);
Assert_VM_notNull(jfrEventClass);   --> **crashes here** 
...

jdk/jfr/Event lives in jdk.jfr, so internalFindClassUTF8(..., systemClassLoader, 0) returns NULL, Assert_VM_notNull aborts the VM in JFRHelpers's during bootstrap; before main runs. So hello, world never prints, and the Started recording banner never gets a chance either. That is why the jdk.jfr is injected to root module set in the boot time using jdk.module.addmods.<n> property when both EnableOpenJ9ExperimentalFlightRecording and StartFlightRecording flags are provided.

On jcmd and the JFR dependency:
Agreed the jcmd tool has no JFR dependency; it's pure AttachAPI. The dependency is in the target: JFR.start/stop/dump/configure invoke jdk.jfr.internal.dcmd.DCmd*, which live in jdk.jfr. -XX:+EnableOpenJ9ExperimentalFlightRecording turns on V2 support but does not pull jdk.jfr into the module graph. So for "flag set, no -XX:StartFlightRecording, JFR.start via jcmd later", jdk.jfr isn't resolved during boot time and has to be brought in on demand. That's what ensureJfrModuleAvailable() in JFRHelpers.java does. If it can't be resolved (e.g. a jlinked image without the module), the DCmd path now reports "Flight Recorder can not be enabled." and does no JFR work, so there's no hard dependency in that case.

[JasonFengJ9]

Neither applies here, so even if jdk.jfr is in the image but never gets resolved into the boot layer.

Thanks the detailed analysis @tomal-majumder

jdk.jfr is part of boot modules, it seems jlink image bootup differently and jdk.jfr wasn't resolved unless loading explicitly.

Agreed the jcmd tool has no JFR dependency; it's pure AttachAPI.

In this case, please update the commit message to remove jcmd reference related to JFR operation and jdk.jfr module resolution issue.

[tomal-majumder]

Neither applies here, so even if jdk.jfr is in the image but never gets resolved into the boot layer.

Thanks the detailed analysis @tomal-majumder

jdk.jfr is part of boot modules, it seems jlink image bootup differently and jdk.jfr wasn't resolved unless loading explicitly.

Agreed the jcmd tool has no JFR dependency; it's pure AttachAPI.

In this case, please update the commit message to remove jcmd reference related to JFR operation and jdk.jfr module resolution issue.

Thanks for the suggestion! Commit message updated!

[tajila]

jenkins test sanity,extended.functional alinux64 jdk17,jdk21

[tajila]

jenkins compile win jdk11,jdk17

[tajila]

jenkins test sanity aix jdk17