JDK-8251261 : CDS dumping should not clear states in live classes
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2020-08-06
  • Updated: 2024-11-22
  • Resolved: 2020-09-24
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 16
16 b18Fixed
Related Reports
Relates :  
Description
The following test fails in the JDK16 CI:

runtime/cds/appcds/javaldr/GCDuringDump.java

Here's a snippet from the log file:

[1.342s][warning][cds] Skipping java/util/stream/Collectors$$Lambda$8+0x00000008c005d820: Hidden class
[1.342s][warning][cds] Skipping jdk/internal/module/DefaultRoots$$Lambda$9+0x00000008c005fa00: Hidden class
[1.343s][info   ][cds] Number of classes 1303
[1.343s][info   ][cds]     instance classes   =  1189
[1.343s][info   ][cds]     obj array classes  =   106
[1.343s][info   ][cds]     type array classes =     8
[1.343s][info   ][cds] Updating ConstMethods ... 
[1.356s][info   ][cds] done. 
[1.356s][info   ][cds] Removing unshareable information ... 
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000100e25620, pid=27421, tid=20483
#
# JRE version: Java(TM) SE Runtime Environment (16.0+10) (fastdebug build 16-ea+10-370)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-ea+10-370, interpreted mode, tiered, z gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x4d2620]  ClassLoaderData::oops_do(OopClosure*, int, bool)+0x20
#
# Core dump will be written. Default location: core.27421
#
# An error report file with more information is saved as:
# /scratch/mesos/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S2020/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c5d2e18c-957b-4655-a90a-aed7f0152c1e/runs/c9e85a32-daad-48a3-a282-d4c906a0627c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/0/hs_err_pid27421.log
[1.374s][info   ][cds] done. 
[1.374s][info   ][cds] Scanning all metaspace objects ... 
[1.374s][info   ][cds] Allocating RW objects ... 
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
];
 stderr: []
 exitValue = 134

Here's the crashing thread's stack:


---------------  T H R E A D  ---------------

Current thread (0x00007fb85dc33d60):  GCTaskThread "ZWorker#0" [stack: 0x000070000fa88000,0x000070000fb88000] [id=20483]

Stack: [0x000070000fa88000,0x000070000fb88000],  sp=0x000070000fb81bc0,  free space=998k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x4d2620]  ClassLoaderData::oops_do(OopClosure*, int, bool)+0x20
V  [libjvm.dylib+0x112fb0b]  void OopOopIterateDispatch<ZMarkBarrierOopClosure<false> >::Table::oop_oop_iterate<InstanceKlass, oop>(ZMarkBarrierOopClosure<false>*, oop, Klass*)+0x4b
V  [libjvm.dylib+0x1129b90]  void oopDesc::oop_iterate<ZMarkBarrierOopClosure<false> >(ZMarkBarrierOopClosure<false>*)+0xe0
V  [libjvm.dylib+0x112a1de]  ZMark::mark_and_follow(ZMarkCache*, ZMarkStackEntry)+0x1ee
V  [libjvm.dylib+0x112ab9b]  bool ZMark::drain_and_flush<ZMarkNoTimeout>(ZMarkStripe*, ZMarkThreadLocalStacks*, ZMarkCache*, ZMarkNoTimeout*)+0x5b
V  [libjvm.dylib+0x112aa74]  ZMark::work_without_timeout(ZMarkCache*, ZMarkStripe*, ZMarkThreadLocalStacks*)+0xa4
V  [libjvm.dylib+0x112af02]  ZMark::work(unsigned long long)+0xe2
V  [libjvm.dylib+0x1154bba]  ZTask::GangTask::work(unsigned int)+0x1a
V  [libjvm.dylib+0x110632d]  GangWorker::run_task(WorkData)+0x5d
V  [libjvm.dylib+0x11063ec]  GangWorker::loop()+0x2c
V  [libjvm.dylib+0x1005297]  Thread::call_run()+0x1b7
V  [libjvm.dylib+0xdca75f]  thread_native_entry(Thread*)+0x15f
C  [libsystem_pthread.dylib+0x3661]  _pthread_body+0x154
C  [libsystem_pthread.dylib+0x350d]  _pthread_body+0x0
C  [libsystem_pthread.dylib+0x2bf9]  thread_start+0xd


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000030
Comments
Changeset: 8b85c3a6 Author: Ioi Lam <iklam@openjdk.org> Date: 2020-09-24 19:19:53 +0000 URL: https://git.openjdk.java.net/jdk/commit/8b85c3a6
24-09-2020

Looks like ZGC is concurrently scanning the Klass mirrors while CDS is clearing the states in the Klasses (probably changing the classes into a state where such scanning will fail). We should fix CDS by not clearing the states of the "live" Klasses, but will instead only clear the states of "copies" of the Klasses (which will not be seen by the GC). This is already done in the dynamic archiving code (dynamicArchive.cpp), but the static archiving code (metaspaceShared.cpp) has a different code path.
17-09-2020

ILW = HLM = P3
11-08-2020