[GR-38674] Fix JFR-related UnsatisfiedLinkErrors.

[graalvmbot]

By default, JFR support is disabled in Native Image. If any JFR functionality is accessed at run-time, Native Image throws a java.lang.UnsatisfiedLinkError at the moment, e.g.:

jdk.jfr.internal.JVM.isExcluded(Ljava/lang/Class;)Z [symbol: Java_jdk_jfr_internal_JVM_isExcluded or Java_jdk_jfr_internal_JVM_isExcluded__Ljava_lang_Class_2]
	at com.oracle.svm.core.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:152)
	at com.oracle.svm.core.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:41)
	at jdk.jfr@25/jdk.jfr.internal.JVM.isExcluded(Native Method)
	at jdk.jfr@25/jdk.jfr.internal.MetadataRepository.register(MetadataRepository.java:137)
	at jdk.jfr@25/jdk.jfr.internal.MetadataRepository.register(MetadataRepository.java:133)
	at jdk.jfr@25/jdk.jfr.FlightRecorder.register(FlightRecorder.java:124)

This PR fixes that by ensuring that certain JFR substitutions are used even if JFR support is disabled.

[roberttoyonaga]

Is the main change here recomputing JVMSupport.notAvailable so that the JDK-level JFR code knows that JFR is not supported? Then, in case JFR calls to the VM are somehow still made, you've kept the substitutions and now throw a descriptive error instead of UnsatisfiedLinkError?

[roberttoyonaga]

Why are methods like Target_jdk_jfr_internal_JVM#getAllEventClasses() and Target_jdk_jfr_internal_JVM#getTicksFrequency() not guarded by HasJfrSupport.get()? Will this make JFR-related classes reachable even though users won't actually be able to use JFR?

[christianhaeubl]

Those methods don't pull in anything problematic, so we can support them trivially even if the JFR support is disabled (e.g., Target_jdk_jfr_internal_JVM#getAllEventClasses will just return an empty list if the JFR support is disabled).

[christianhaeubl]

Is the main change here recomputing JVMSupport.notAvailable so that the JDK-level JFR code knows that JFR is not supported? Then, in case JFR calls to the VM are somehow still made, you've kept the substitutions and now throw a descriptive error instead of UnsatisfiedLinkError?

Yes, JVMSupport.notAvailable is the most important change. jdk.jfr.internal.JVM contains a bunch of methods that are not really tightly coupled to JFR (e.g., getPid() or isContainerized()). So, it feels safer to just assume that there are applications that might call some of these methods directly.

[roberttoyonaga]

Thank you!