JDK-8205376 : Release Note: JVM Crash during G1 GC
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u181,10.0.2,11
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2018-06-19
  • Updated: 2022-07-12
  • Resolved: 2018-06-21
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 10 JDK 11 JDK 8
10.0.2Resolved 11Resolved 8u162Resolved
Description
A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the `ClassLoaderData/SystemDictionary`, and its `_java_mirror` or `_class_loader` fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass.

In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash.

This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded. 
Comments
Details on the problem and the fix for this crash: Problem: A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the ClassLoaderData/SystemDictionary, and its _java_mirror or _class_loader fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will wrongly unload that klass. In this particular crash, while G1 is doing concurrent marking and has prepared its list of unreachable classes, JVMTI on a Java thread can traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 does not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloads classes as per its prior knowledge of unreachable classes. But when these JNIHandles are later scanned, it leads to a crash. Solution: This fix informs G1's SATB that a klass has been resurrected and it should not be unloaded.
20-06-2018