Bug ID: JDK-8129108 nmethod related crash in CMS

Versions (Unresolved/Resolved/Fixed)

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 8	JDK 9
8u60Fixed	9 b74Fixed

#  Internal Error (hotspot/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:4472), pid=16267, tid=0xf36ffb70
#  assert(_collector->should_unload_classes() || (_collector->CMSCollector::roots_scanning_options() & GenCollectedHeap::SO_AllCodeCache)) failed: if we didn't scan the code cache, we have to be ready to drop nmethods with expired weak oops
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20150617220601.iklam.jdk9_rt-b00)
# Java VM: Java HotSpot(TM) Client VM (1.9.0-internal-fastdebug-20150617220601.iklam.jdk9_rt-b00 mixed mode, sharing linux-x86 )



Current thread (0xf6322000):  GCTaskThread [stack: 0xf367f000,0xf3700000] [id=16282]

Stack: [0xf367f000,0xf3700000],  sp=0xf36ff050,  free space=512k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xa8df2a]  VMError::report_and_die()+0x19a;;  VMError::report_and_die()+0x19a
V  [libjvm.so+0x3dfcd6]  report_vm_error(char const*, int, char const*, char const*)+0x76;;  report_vm_error(char const*, int, char const*, char const*)+0x76
V  [libjvm.so+0x3aac44]  CMSParInitialMarkTask::work(unsigned int)+0x244;;  CMSParInitialMarkTask::work(unsigned int)+0x244
V  [libjvm.so+0xae2404]  GangWorker::loop()+0x254;;  GangWorker::loop()+0x254
V  [libjvm.so+0x898320]  java_start(Thread*)+0x100;;  java_start(Thread*)+0x100


Seems to be related to JDK-8085965.

Bugs found by nightly testing. Verified by passed nightly.
26-07-2017
SQE is okay to backport this fix to 8u60
29-06-2015
This bug exists in jdk9-b68 as well. I could reproduce the problem with -XX:-CMSClassUnloadingEnabled option: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/repool/java_re/builds/workspace/9-2-build-solaris-sparcv9/jdk9/2833/hotspot/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp: 4476), pid=16337, tid=0x0000000000000010 # assert(_collector->should_unload_classes() \|\| (_collector->CMSCollector::roots_scanning_options() & GenCollectedHeap::SO_AllCodeCache)) failed: if we didn't scan the code cache, we have to be ready to drop nmethods with expired weak oops # # JRE version: Java(TM) SE Runtime Environment (9.0-b68) (build 1.9.0-ea-fastdebug-b68) # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-fastdebug-b68 mixed mode solaris-sparc ) # Core dump will be written. Default location: /export3/users/poonam/ws/hs-rt-cms_classunloading/hotspot/test/closed/tonga/src/core or core.16337 # # An error report file with more information is saved as: # /export3/users/poonam/ws/hs-rt-cms_classunloading/hotspot/test/closed/tonga/src/hs_err_pid16337.log Phoning home... Using server: 10.161.186.18, port 4711 # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # So, when we are not unloading classes, we should add SO_AllCodeCache to root_scanning_options.
18-06-2015
I looking at this bug and trying to find the appropriate place where we should check for should_unload_classes() and add SO_AllCodeCache to _roots_scanning_options if _should_class_unloading is false.
18-06-2015
CMSCollector::_roots_scanning_options must be kept in sync with the should_unload_classes() state. If we are not unloading classes they should contain SO_AllCodeCache.
18-06-2015
This bug is currently blocking integration from jdk9/hs-rt to jdk9/hs.
18-06-2015