Graal: Compiled image crashes at runtime with UnsatisfiedLinkError when using the JFR API

Created on 5 Apr 2020  路  11Comments  路  Source: oracle/graal

Calling certain native methods from within the Java 11 JDK's JFR libraries causes an UnsatisfiedLinkError at runtime.

  1. git clone https://github.com/kittylyst/jfr-parser_repro_case_graalvm_linkage_bug-bevans.git
  2. mvn clean compile assembly:single
  3. java -jar target/jfr-graal-repro-0.1.0-jar-with-dependencies.jar
  4. native-image --verbose --native-image-info -H:+JNI -jar target/jfr-graal-repro-0.1.0-jar-with-dependencies.jar
  5. ./jfr-graal-repro-0.1.0-jar-with-dependencies
  6. BOOM!

    • GraalVM version - 20.0 release & latest snapshot
    • JDK major version: 11
    • OS: macOS Catalina
    • Architecture: AMD64
$ native-image --verbose --native-image-info -H:+JNI -jar target/jfr-graal-repro-0.1.0-jar-with-dependencies.jar
Shutdown Server(pid: 43797, port: 56296)
StartServer [
/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/bin/java \
-cp \
/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/llvm-wrapper-shadowed.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/svm.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/objectfile.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/llvm-platform-specific-shadowed.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/javacpp-shadowed.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/svm-llvm.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/pointsto.jar \
-XX:+UseParallelGC \
-XX:+UnlockExperimentalVMOptions \
-XX:+EnableJVMCI \
-Dtruffle.TrustAllTruffleRuntimeProviders=true \
-Dtruffle.TruffleRuntime=com.oracle.truffle.api.impl.DefaultTruffleRuntime \
-Dgraalvm.ForcePolyglotInvalid=true \
-Dgraalvm.locatorDisabled=true \
-Dsubstratevm.IgnoreGraalVersionCheck=true \
-Djava.lang.invoke.stringConcat=BC_SB \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.runtime=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.code=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.aarch64=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.amd64=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.meta=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.hotspot=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.services=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.common=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.code.site=ALL-UNNAMED \
--add-exports \
jdk.internal.vm.ci/jdk.vm.ci.code.stack=ALL-UNNAMED \
--add-opens \
jdk.internal.vm.compiler/org.graalvm.compiler.debug=ALL-UNNAMED \
--add-opens \
jdk.internal.vm.compiler/org.graalvm.compiler.nodes=ALL-UNNAMED \
--add-opens \
jdk.unsupported/sun.reflect=ALL-UNNAMED \
--add-opens \
java.base/jdk.internal.module=ALL-UNNAMED \
--add-opens \
java.base/jdk.internal.ref=ALL-UNNAMED \
--add-opens \
java.base/jdk.internal.reflect=ALL-UNNAMED \
--add-opens \
java.base/java.io=ALL-UNNAMED \
--add-opens \
java.base/java.lang=ALL-UNNAMED \
--add-opens \
java.base/java.lang.reflect=ALL-UNNAMED \
--add-opens \
java.base/java.lang.invoke=ALL-UNNAMED \
--add-opens \
java.base/java.lang.ref=ALL-UNNAMED \
--add-opens \
java.base/java.net=ALL-UNNAMED \
--add-opens \
java.base/java.nio=ALL-UNNAMED \
--add-opens \
java.base/java.nio.file=ALL-UNNAMED \
--add-opens \
java.base/java.security=ALL-UNNAMED \
--add-opens \
java.base/javax.crypto=ALL-UNNAMED \
--add-opens \
java.base/java.util=ALL-UNNAMED \
--add-opens \
java.base/java.util.concurrent.atomic=ALL-UNNAMED \
--add-opens \
java.base/sun.security.x509=ALL-UNNAMED \
--add-opens \
java.base/jdk.internal.logger=ALL-UNNAMED \
--add-opens \
org.graalvm.sdk/org.graalvm.nativeimage.impl=ALL-UNNAMED \
--add-opens \
org.graalvm.sdk/org.graalvm.polyglot=ALL-UNNAMED \
--add-opens \
org.graalvm.truffle/com.oracle.truffle.polyglot=ALL-UNNAMED \
--add-opens \
org.graalvm.truffle/com.oracle.truffle.api.impl=ALL-UNNAMED \
-XX:+UseJVMCINativeLibrary \
-Xss10m \
-Duser.country=US \
-Duser.language=en \
-Djava.awt.headless=true \
-Dorg.graalvm.version=20.1.0-dev \
-Dorg.graalvm.config= \
-Dcom.oracle.graalvm.isaot=true \
-Djava.system.class.loader=com.oracle.svm.hosted.NativeImageSystemClassLoader \
-Xshare:off \
--module-path \
/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/truffle/truffle-api.jar \
-javaagent:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/svm.jar \
-Djdk.internal.lambda.disableEagerInitialization=true \
-Djdk.internal.lambda.eagerlyInitialize=false \
-Djava.lang.invoke.InnerClassLambdaMetafactory.initializeLambdas=false \
-Xmx6871947672 \
-Xms1g \
-Dgraal.LogFile=%e \
com.oracle.svm.hosted.server.NativeImageBuildServer \
-port=0 \
-logFile=/Users/bevans/.native-image/machine-id-hostid-0/session-id-caf/server-id-3952be546c6ea5b131d6ba8cdb05d70fc9cce7b6acd2ba53535e533330bcaa2c55d8318a5ac86efdd1a6b66c6d72438b9989a9f85362c4ed2508229b1ce19573/server.log \

]
Build on Server(pid: 58435, port: 57642)*
SendBuildRequest [
-task=com.oracle.svm.hosted.NativeImageGeneratorRunner
-imagecp
/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/llvm-wrapper-shadowed.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/svm.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/objectfile.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/llvm-platform-specific-shadowed.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/javacpp-shadowed.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/svm-llvm.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/builder/pointsto.jar:/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/library-support.jar:/Users/bevans/external-gh/jfr-parser_repro_case_graalvm_linkage_bug-bevans/target/jfr-graal-repro-0.1.0-jar-with-dependencies.jar
-H:Path=/Users/bevans/external-gh/jfr-parser_repro_case_graalvm_linkage_bug-bevans
-H:+DumpTargetInfo
-H:+JNI
-H:Class=com.newrelic.JFRFileParser
-H:Name=jfr-graal-repro-0.1.0-jar-with-dependencies
-H:CLibraryPath=/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/clibraries/darwin-amd64
]
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]    classlist:   1,145.68 ms,  0.96 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]        (cap):   5,194.60 ms,  0.96 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]        setup:   6,747.14 ms,  0.96 GB
# Building image for target platform: org.graalvm.nativeimage.Platform$DARWIN_AMD64
# Using native toolchain:
#   Name: LLVM (clang)
#   Vendor: apple
#   Version: 10.0.1
#   Target architecture: x86_64
#   Path: /usr/bin/cc
# Using CLibrary: com.oracle.svm.core.c.libc.GLibc
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]     (clinit):     307.26 ms,  1.24 GB
# Static libraries:
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/libnet.a
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/libjava.a
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/libzip.a
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/libnio.a
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/clibraries/darwin-amd64/libffi.a
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/clibraries/darwin-amd64/libdarwin.a
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/clibraries/darwin-amd64/liblibchelper.a
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/clibraries/darwin-amd64/libjvm.a
#   ../../../../../../Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home/lib/svm/clibraries/darwin-amd64/libstrictmath.a
# Other libraries: pthread,-framework Foundation,dl,z
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]   (typeflow):   4,293.18 ms,  1.24 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]    (objects):   3,461.46 ms,  1.24 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]   (features):     169.49 ms,  1.24 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]     analysis:   8,443.81 ms,  1.24 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]     universe:     315.61 ms,  1.24 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]      (parse):     754.65 ms,  1.24 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]     (inline):   1,057.48 ms,  1.69 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]    (compile):   5,465.35 ms,  2.29 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]      compile:   7,740.20 ms,  2.29 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]        image:   1,044.58 ms,  2.29 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]        write:     304.68 ms,  2.29 GB
[jfr-graal-repro-0.1.0-jar-with-dependencies:58435]      [total]:  25,966.63 ms,  2.29 GB

Add any other information about the problem here. Especially important are stack traces or log output. Feel free to link to gists or to screenshots if necessary.

$ ./jfr-graal-repro-0.1.0-jar-with-dependencies bmds-pid-213-2020_04_03_15_18_41.jfr 
Exception in thread "main" java.lang.UnsatisfiedLinkError: jdk.jfr.internal.JVM.getTypeId(Ljava/lang/Class;)J [symbol: Java_jdk_jfr_internal_JVM_getTypeId or Java_jdk_jfr_internal_JVM_getTypeId__Ljava_lang_Class_2]
    at com.oracle.svm.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:145)
    at com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:57)
    at jdk.jfr.internal.JVM.getTypeId(JVM.java)
    at jdk.jfr.internal.Type.getTypeId(Type.java:115)
    at jdk.jfr.internal.AnnotationConstruct.getAnnotationElement(AnnotationConstruct.java:112)
    at jdk.jfr.internal.AnnotationConstruct.getAnnotation(AnnotationConstruct.java:92)
    at jdk.jfr.internal.AnnotationConstruct.hasUnsigned(AnnotationConstruct.java:131)
    at jdk.jfr.ValueDescriptor.isUnsigned(ValueDescriptor.java:319)
    at jdk.jfr.FlightRecorderPermission$InternalAccess.isUnsigned(FlightRecorderPermission.java:187)
    at jdk.jfr.consumer.RecordedObject.getValue(RecordedObject.java:183)
    at jdk.jfr.consumer.RecordedObject.getLong(RecordedObject.java:568)
    at com.newrelic.jfr.summarizers.PerThreadObjectAllocationInNewTLABSummarizer.apply(PerThreadObjectAllocationInNewTLABSummarizer.java:37)
    at com.newrelic.jfr.summarizers.ObjectAllocationInNewTLABSummarizer.lambda$apply$0(ObjectAllocationInNewTLABSummarizer.java:34)
    at java.util.Optional.ifPresent(Optional.java:183)
    at com.newrelic.jfr.summarizers.ObjectAllocationInNewTLABSummarizer.apply(ObjectAllocationInNewTLABSummarizer.java:29)
    at com.newrelic.JFRFileParser.run(JFRFileParser.java:50)
    at com.newrelic.JFRFileParser.main(JFRFileParser.java:70)

Let me know if you need more details (or to try something) - will retry on Linux when I get near a dev machine. Thanks!

bug native-image

All 11 comments

will retry on Linux when I get near a dev machine.

It's the same on Linux. It fails because it relies on the native method implementation for
jdk.jfr.internal.JVM.getTypeId which we currently do not support when building native images. I.e. none of the static jdk libs that we link the image against provides Java_jdk_jfr_internal_JVM_getTypeId (hotspot finds the symbol in lib/server/libjvm.so as jfr_type_id (accessed via JNI Java_jdk_jfr_internal_JVM_getTypeId).

We could add an implementation of Java_jdk_jfr_internal_JVM_getTypeId to https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.native.jvm.posix/src/JvmFuncs.c. But since that method returns a hotspot specific JFR traceid I'm not sure how practical it is to provide a meaningful implementation for native-image.
cc @tzezula @christianwimmer

Thanks for such prompt attention - it's really appreciated!

The case that I'm interested in is after-the-fact parsing of a JFR dump file, not live handling of JFR events within a Graal native image. My understanding is that what we're actually looking at here should be the klassid's of the JVM that produced the dump file (which is no longer running). Does that help at all? This should just be file parsing, unless I've misunderstood something.

On another note - did I miss something during the native-image step that would have told me that I was trying to use an unsupported native API?

My understanding is that what we're actually looking at here should be the klassid's of the JVM that produced the dump file (which is no longer running). Does that help at all? This should just be file parsing, unless I've misunderstood something.

Yes that's also what I see. This is triggered by https://github.com/kittylyst/jfr-parser_repro_case_graalvm_linkage_bug-bevans/blob/240d36c88aa0108230d5f4175b08ccf585b2c7d3/src/main/java/com/newrelic/jfr/summarizers/PerThreadObjectAllocationInNewTLABSummarizer.java#L37
The implementation of RecordedObject.getLong uses jdk.jfr.ValueDescriptor.isUnsigned and that leads to jdk.jfr.internal.AnnotationConstruct.getAnnotationElement where we have:

    private AnnotationElement getAnnotationElement(Class<? extends Annotation> clazz) {
        // if multiple annotation elements with the same name exists, prioritize
        // the one with the same id. Note, id alone is not a guarantee, since it
        // may differ between JVM instances.
        long id = Type.getTypeId(clazz);
        String className = clazz.getName();
        for (AnnotationElement a : getUnmodifiableAnnotationElements()) {
            if (a.getTypeId() == id && a.getTypeName().equals(className)) {
                return a;
            }
        }
        for (AnnotationElement a : getUnmodifiableAnnotationElements()) {
            if (a.getTypeName().equals(className)) {
                return a;
            }
        }
        return null;
    }

This implementation assumes that we can access the typeid of the tlabSize field juuuust fine. The comment says that it does this so that it can disambiguate in case that there are more Unsigned.class annotations on the fields type. But as also stated in the comment this can only work if the trace is written by the same JVM instance that is now reading the trace. ..... Hmmmmm

For your use-case you might be able to steer around this mess by providing your own implementation of Java_jdk_jfr_internal_JVM_getTypeId as @CFunction that returns -1.

After staring at this for a bit and some more coffee - I think I see what's happening here:

The first for-loop is an attempt to give better guarantees for the case where the RecordedEvent was generated by the currently running JVM (e.g. the Java 14 Streaming case) - but if that fails, as it always will for the "cold case" parsing case, then the second for loop kicks in and does the best it can, which is a pure name-based match. Does that sound about right?

Will give the private impl of Java_jdk_jfr_internal_JVM_getTypeId a shot - many thanks.

The first for-loop is an attempt to give better guarantees for the case where the RecordedEvent was generated by the currently running JVM (e.g. the Java 14 Streaming case) - but if that fails, as it always will for the "cold case" parsing case, then the second for loop kicks in and does the best it can, which is a pure name-based match. Does that sound about right?

I'm no JFR expert but that's also how I read this code.

We have some intrinsifications in SubstrateGraphBuilderPlugins to remove the instrumentation that JFR is doing, so that enabling JFR at image build time does not leak into images. The package names there are for JDK 8 and changed for JDK 11, so the first step is to enable these intrinsifications also for JDK 11. Then there might be more intrinsifications necessary if the JFR implementation got extended in JDK 11.

I've updated the test repo with a dummy impl and tried to force native-image to link the extra symbols - but no luck. Is there an obvious way to force this? And should I be using a static or shared library for this?

With the changes on my fork you can build with:

> JAVA_HOME=$HOME/OLabs/graalvm-ce-java11-20.0.0 mvn clean package
[INFO] Scanning for projects...
[INFO] 
[INFO] -----------------< com.newrelic.infra:jfr-graal-repro >-----------------
[INFO] Building jfr-graal-repro 0.1.0
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ jfr-graal-repro ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ jfr-graal-repro ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ jfr-graal-repro ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 9 source files to /home/pwoegere/OLabs/issues/2318/jfr-parser_repro_case_graalvm_linkage_bug-bevans/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ jfr-graal-repro ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/pwoegere/OLabs/issues/2318/jfr-parser_repro_case_graalvm_linkage_bug-bevans/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ jfr-graal-repro ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ jfr-graal-repro ---
[INFO] No tests to run.
[INFO] 
[INFO] --- maven-jar-plugin:3.2.0:jar (default-jar) @ jfr-graal-repro ---
[INFO] Building jar: /home/pwoegere/OLabs/issues/2318/jfr-parser_repro_case_graalvm_linkage_bug-bevans/target/jfr-graal-repro-0.1.0.jar
[INFO] 
[INFO] --- maven-source-plugin:3.2.0:jar-no-fork (generate-source-jar) @ jfr-graal-repro ---
[INFO] Building jar: /home/pwoegere/OLabs/issues/2318/jfr-parser_repro_case_graalvm_linkage_bug-bevans/target/jfr-graal-repro-0.1.0-sources.jar
[INFO] 
[INFO] --- maven-jar-plugin:3.2.0:jar (empty-javadoc-jar) @ jfr-graal-repro ---
[INFO] Building jar: /home/pwoegere/OLabs/issues/2318/jfr-parser_repro_case_graalvm_linkage_bug-bevans/target/jfr-graal-repro-0.1.0-javadoc.jar
[INFO] 
[INFO] --- maven-assembly-plugin:3.2.0:single (make-assembly) @ jfr-graal-repro ---
[INFO] Building jar: /home/pwoegere/OLabs/issues/2318/jfr-parser_repro_case_graalvm_linkage_bug-bevans/target/jfr-graal-repro-0.1.0-jar-with-dependencies.jar
[INFO] 
[INFO] --- native-image-maven-plugin:20.0.0:native-image (default) @ jfr-graal-repro ---
[INFO] ImageClasspath Entry: com.newrelic.infra:jfr-graal-repro:jar:0.1.0 (file:///home/pwoegere/OLabs/issues/2318/jfr-parser_repro_case_graalvm_linkage_bug-bevans/target/jfr-graal-repro-0.1.0.jar)
[INFO] Executing: /home/pwoegere/OLabs/graalvm-ce-java11-20.0.0/bin/native-image -cp /home/pwoegere/OLabs/issues/2318/jfr-parser_repro_case_graalvm_linkage_bug-bevans/target/jfr-graal-repro-0.1.0.jar --no-fallback -H:Class=com.newrelic.JFRFileParser -H:Name=JFRFileParser
Build on Server(pid: 23310, port: 32817)
[JFRFileParser:23310]    classlist:     122.83 ms,  1.00 GB
[JFRFileParser:23310]        (cap):     370.79 ms,  1.00 GB
[JFRFileParser:23310]        setup:     585.46 ms,  1.00 GB
[JFRFileParser:23310]   (typeflow):   5,413.71 ms,  1.00 GB
[JFRFileParser:23310]    (objects):   7,536.24 ms,  1.00 GB
[JFRFileParser:23310]   (features):     122.69 ms,  1.00 GB
[JFRFileParser:23310]     analysis:  13,287.41 ms,  1.00 GB
[JFRFileParser:23310]     (clinit):     170.11 ms,  1.00 GB
[JFRFileParser:23310]     universe:     419.36 ms,  1.00 GB
[JFRFileParser:23310]      (parse):     415.99 ms,  1.00 GB
[JFRFileParser:23310]     (inline):     740.58 ms,  1.00 GB
[JFRFileParser:23310]    (compile):   3,027.98 ms,  1.00 GB
[JFRFileParser:23310]      compile:   4,500.21 ms,  1.00 GB
[JFRFileParser:23310]        image:     672.39 ms,  1.00 GB
[JFRFileParser:23310]        write:     115.27 ms,  1.00 GB
[JFRFileParser:23310]      [total]:  19,769.32 ms,  1.00 GB
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  23.087 s
[INFO] Finished at: 2020-04-16T13:41:14+02:00
[INFO] ------------------------------------------------------------------------

Then run the native image with

> ./target/JFRFileParser recording.jfr 
Summarizing a period...
...

Note that in addition to providing a dummy implementation for jdk.jfr.internal.JVM#getTypeId you also needed a proxy configuration for the dynamic proxy that is used by your application code. See: https://github.com/olpaw/jfr-parser_repro_case_graalvm_linkage_bug-bevans/blob/master/src/main/resources/META-INF/native-image/proxy-config.json

That's got it fixed. Thanks for the patch @olpaw - PR'd & merged to the test repo. I think we can go ahead and close this issue now?

Was this page helpful?
0 / 5 - 0 ratings