Skip to content

[GR-38674] Fix JFR-related UnsatisfiedLinkErrors. #11203

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

graalvmbot
Copy link
Collaborator

@graalvmbot graalvmbot commented May 15, 2025

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.

@oracle-contributor-agreement oracle-contributor-agreement bot added the OCA Verified All contributors have signed the Oracle Contributor Agreement. label May 15, 2025
Copy link
Collaborator

@roberttoyonaga roberttoyonaga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@@ -169,6 +191,9 @@ public static void setMiscellaneous(long eventTypeId, long value) {
/** See {@link JVM#getThreadId}. */
@Substitute
public static long getThreadId(Thread t) {
if (!HasJfrSupport.get()) {
throw jfrNotSupportedException();
}
return SubstrateJVM.getThreadId(t);
}

Copy link
Collaborator

@roberttoyonaga roberttoyonaga May 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OCA Verified All contributors have signed the Oracle Contributor Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants