JDK-8203664 : JFR start failure after AppCDS archive created with JFR StartFlightRecording
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-05-22
  • Updated: 2020-04-27
  • Resolved: 2018-06-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 Other
11 b20Fixed 12Fixed openjdk8u262Fixed
Related Reports
Relates :  
JDK-8239140 - Backport JFR to OpenJDK 8
Sub Tasks
JDK-8205622 :  
Release Note: JFR Start Failure After AppCDS Archive Created with JFR StartFlightRecording - Closed
Description
This happened in 11-b14.

1. I created the AppCDS archive with -XX:StartFlightRecording=dumponexit=true

2. Archive created successfully AFAICT

3. Went to run my app with 
-XX:+UnlockCommercialFeatures -XX:StartFlightRecording=dumponexit=true -Xshare:on -XX:+UnlockCommercialFeatures -XX:SharedArchiveFile=App.jsa -XX:+UseAppCDS

And this happened:

Error occurred during initialization of VM
Failure when starting JFR on_vm_start

- The app would start ok with -XX:+UnlockCommercialFeatures -XX:StartFlightRecording=dumponexit=true -Xshare:off -XX:+UnlockCommercialFeatures -XX:SharedArchiveFile=App.jsa -XX:+UseAppCDS 

- We re-created the archive without  -XX:StartFlightRecording=dumponexit=true and then the app booted correctly with all of it: -XX:+UnlockCommercialFeatures -XX:StartFlightRecording=dumponexit=true -Xshare:on -XX:+UnlockCommercialFeatures -XX:SharedArchiveFile=App.jsa -XX:+UseAppCDS
Comments
Replacing jdk8u-fix-request with link to JDK-8239140
17-02-2020
RFC: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/011063.html
30-01-2020
Regarding the assert failure during dumping: # Internal Error (/home/iklam/jdk/abe/open/src/hotspot/share/classfile/klassFactory.cpp:241), pid=8345, tid=8346 # assert(cached_class_file == __null) failed: Sanity I think it is due to some classes being redefined by JFR. Classes like the following (with my debug output): klass java/io/FileInputStream source __VM_RedefineClasses__ is_anonymous false shared_classpath_index 0 The assert should be enclosed by some condition such as if the source is not __VM_RedefineClasses__ The other assert in metaspaceShared.cpp: if (ik->shared_classpath_index() == UNREGISTERED_INDEX) { guarantee(ik->loader_type() == 0, "Class loader type must not be set for this class %s", ik->name()->as_C_string()); } Just checking shared classpath index == UNREGISTERD_INDEX is insufficient. Some classes may not have shared classpath index set (default value is -1). com/sun/proxy/$Proxy15 source __JVM_DefineClass__ is_anonymous false shared_classpath_index -1 I think the "if" statement could be the following to cover both the shared_classpath_index equals -1 or equals UNREGISTERED_INDEX. if (ik->shared_classpath_index() < 0) { After fixing the above dumping issues, I saw the runtime issue reported by Eric. With -XX:+TraceExceptions, I saw the following exceptions: [0.424s][info ][exceptions] Exception <a 'java/lang/IllegalAccessError'{0x00000004a42980d0}: class sun.nio.ch.FileChannelImpl (in module java.base) cannot access class jdk.jfr.events.FileReadEvent (in module jdk.jfr) because module jdk.jfr does not export jdk.jfr.events to module java.base> [0.535s][info ][exceptions] Exception <a 'java/lang/StackOverflowError'{0x00000004a4294708}: class java.lang.Throwable (in module java.base) cannot access class jdk.jfr.internal.instrument.ThrowableTracer (in module jdk.jfr) because module java.base does not read module jdk.jfr> (0x00000004a4294708) A fix is to add more exports statements to the module-info.java of the jdk.jfr module: diff --git a/src/jdk.jfr/share/classes/module-info.java b/src/jdk.jfr/share/classes/module-info.java --- a/src/jdk.jfr/share/classes/module-info.java +++ b/src/jdk.jfr/share/classes/module-info.java @@ -32,6 +32,7 @@ module jdk.jfr { exports jdk.jfr; exports jdk.jfr.consumer; - + exports jdk.jfr.internal.instrument; + exports jdk.jfr.events to java.base; exports jdk.jfr.internal.management to jdk.management.jfr; } Also add the "--add-reads java.base=jdk.jfr" in the command line when running with both CDS and JFR enabled. $MYJDK/bin/java -XX:StartFlightRecording=dumponexit=true --add-reads java.base=jdk.jfr -version
14-06-2018
Seems like -Xshare:dump is not compatible with -XX:StartFlightRecording=dumponexit=true. With the latest repo as of today, I get a crash in fastdebug build: $ java -Xshare:dump -XX:StartFlightRecording=dumponexit=true narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 Allocated shared space: 3221225472 bytes at 0x0000000800000000 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/klassFactory.cpp:241 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/iklam/jdk/abe/open/src/hotspot/share/classfile/klassFactory.cpp:241), pid=8345, tid=8346 # assert(cached_class_file == __null) failed: Sanity # # JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build 11-internal+0-adhoc.iklam.open) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 11-internal+0-adhoc.iklam.open, interpreted mode, tiered, compressed oops, g1 gc, linux-amd64) # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/iklam/core.8345)
23-05-2018