JDK-8215947 : JVM crash with -XX:+DumpSharedSpaces
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11.0.1,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-12-28
  • Updated: 2019-09-09
  • Resolved: 2019-01-03
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 JDK 13
11.0.3-oracleFixed 12 b27Fixed 13Fixed
Related Reports
Relates :  
JDK-8200451 - CDS dump time restricts to interpreter_only mode
Relates :  
JDK-8186842 - Use Java class loaders for creating the CDS archive
Description
The JVM always crashes if running with '-XX:+DumpSharedSpaces'. 
Issue reproduced with 
- 10.0.0+43 (First JDK 10 release)  and later, 
- for example, 11.0.2+7, 12-ea+10 

Issue not reproduced with 
- 9.0.4+11 (Last JDK 9 update) and earlier 

Adding '-XX:-UseCompiler' or '-Xshare:dump' can work around the issue. 

I assume the issue was caused by the fix although not still verified much: 
JDK-8186842: Use Java class loaders for creating the CDS archive 
This fix was integrated to 10-ea+23, and 10-ea+22 doesn't crash with the 
option -XX:+DumpSharedSpaces. 

$ java -XX:+DumpSharedSpaces 
narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 
Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 
Allocated shared space: 3221225472 bytes at 0x0000000800000000 
Loading classes to share ... 
Loading classes to share: done. 
Rewriting and linking classes ... 
Rewriting and linking classes: done 
Number of classes 1229 
    instance classes   =  1168 
    obj array classes  =    53 
    type array classes =     8 
Updating ConstMethods ... done. 
Removing unshareable information ... # 
# A fatal error has been detected by the Java Runtime Environment: 
# 
#  Internal Error (instanceKlass.cpp:2288), pid=28024, tid=28031 
#  guarantee(_dep_context == DependencyContext::EMPTY) failed: must be 
# 
# JRE version: Java(TM) SE Runtime Environment (11.0.2+7) (build 
11.0.2+7-LTS) 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.2+7-LTS, mixed mode, 
tiered, compressed oops, g1 gc, linux-amd64) 
# Core dump will be written. Default location: Core dumps may be processed 
with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping 
to core.28024) 
# 
# An error report file with more information is saved as: 
# /home/yoshiki/hs_err_pid28024.log 
# 
# If you would like to submit a bug report, please visit: 
#   http://bugreport.java.com/bugreport/crash.jsp 
# 
zsh: abort (core dumped)  java -XX:+DumpSharedSpaces
Comments
Fix Request Backporting this fix resolves (arguably the UX) issue with -XX:+DumpSharedSpaces. Patch applies cleanly to 11u and passes runtime/SharedArchiveFile/ tests.
15-02-2019
I'm wondering what nmethods issue is involved at dump time if -XX:-UseCompiler is not specified, and if we need to address the same for dynamic archiving.
03-01-2019
This isn't strictly a "regression" since it doesn't involve functionality that people should be using. There's no reason to use the -XX CDS flags, only the -Xshare:* values should be used.
29-12-2018
Thanks for explaining. So this is not a P2 issue. The "correct" flag to use is '-Xshare:dump'. Obviously testing needs updating to ensure direct use of the -XX flags behaves the same as their -Xshare equivalents.
28-12-2018
CDS dumping can't handle the existence of nmethods, etc, so we disable the JIT here when -Xshare:dump is specified. } else if (match_option(option, "-Xshare:dump")) { if (FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true) != JVMFlag::SUCCESS) { return JNI_EINVAL; } set_mode_flags(_int); // Prevent compilation, which creates objects // -Xshare:on We should do the same thing if -XX:+DumpSharedSpaces is specified without using -Xshare:dump. This hasn't shown up in regular testing because we don't have such a test case. The JIT is not crashing. We just hit an assert in the CDS code that asserts that the JIT shouldn't have compiled anything.
28-12-2018
Is -XX:-UseCompiler just the same as using -Xint ? I don't see that as a fix, just a workaround. Why should the JIT cause a crash here? And why has this not shown up in regular testing? What is different in this context that causes the crash?
28-12-2018
This is also reproducible with latest jdk/jdk repo. The fix would be to explicitly disable UseCompiler whenever -XX:+DumpSharedSpaces is specified.
28-12-2018