After the integration of:
-JDK-8364176 "Serial: Group all class unloading logic at the end of marking phase"
-JDK-8364166 Parallel: Remove the use of soft_ref_policy in Full GC
we see numerous tests crashing with Serial GC. E.g. on Linux:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000ffffb24938cc, pid=3372634, tid=3372642
#
# JRE version: Java(TM) SE Runtime Environment (26.0+10) (fastdebug build 26-ea+10-945)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+10-945, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x16538cc] Compacter::phase2_calculate_new_addr()+0x13ac
Current thread (0x0000ffffac0e3aa0): VMThread "VM Thread" [id=3372642, stack(0x0000ffff94531000,0x0000ffff9472f000) (2040K)]
Stack: [0x0000ffff94531000,0x0000ffff9472f000], sp=0x0000ffff9472cb00, free space=2030k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x16538cc] Compacter::phase2_calculate_new_addr()+0x13ac (klass.hpp:290)
V [libjvm.so+0x164fe1c] SerialFullGC::invoke_at_safepoint(bool)+0x25c (serialFullGC.cpp:725)
V [libjvm.so+0x1660be0] SerialHeap::do_full_collection(bool)+0x394 (serialHeap.cpp:615)
V [libjvm.so+0x9439f4] CollectedHeap::collect_as_vm_thread(GCCause::Cause)+0xb0 (collectedHeap.cpp:371)
V [libjvm.so+0xd2f93c] VM_CollectForMetadataAllocation::doit()+0xb8 (gcVMOperations.cpp:242)
V [libjvm.so+0x18e9090] VM_Operation::evaluate()+0x148 (vmOperations.cpp:74)
V [libjvm.so+0x190b4ec] VMThread::evaluate_operation(VM_Operation*)+0x52c (vmThread.cpp:284)
V [libjvm.so+0x190beec] VMThread::inner_execute(VM_Operation*)+0x3ec (vmThread.cpp:421)
V [libjvm.so+0x190c150] VMThread::loop()+0x88 (vmThread.cpp:487)
V [libjvm.so+0x190c284] VMThread::run()+0xa4 (vmThread.cpp:177)
V [libjvm.so+0x17fa02c] Thread::call_run()+0xac (thread.cpp:243)
V [libjvm.so+0x14da99c] thread_native_entry(Thread*)+0x12c (os_linux.cpp:868)
C [libc.so.6+0x80b50] start_thread+0x300
Windows crashes in a slightly deeper place:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff8f66cb43b, pid=8888, tid=1688
#
# JRE version: Java(TM) SE Runtime Environment (26.0+10) (fastdebug build 26-ea+10-942)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+10-942, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, windows-amd64)
# Problematic frame:
# V [jvm.dll+0x2ab43b] oopDesc::size_given_klass+0x1b
#
--------------- T H R E A D ---------------
Current thread (0x000002314a644420): VMThread "VM Thread" [id=1688, stack(0x000000b1c8400000,0x000000b1c8500000) (1024K)]
Stack: [0x000000b1c8400000,0x000000b1c8500000], sp=0x000000b1c84ff230, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x2ab43b] oopDesc::size_given_klass+0x1b (oop.inline.hpp:191)
V [jvm.dll+0xedc596] Compacter::phase2_calculate_new_addr+0x616 (serialFullGC.cpp:309)
V [jvm.dll+0xedaa24] SerialFullGC::invoke_at_safepoint+0x334 (serialFullGC.cpp:725)
V [jvm.dll+0xee6a05] SerialHeap::do_full_collection+0x1d5 (serialHeap.cpp:617)
V [jvm.dll+0xee66ea] SerialHeap::collect_at_safepoint+0x6a (serialHeap.cpp:557)
V [jvm.dll+0xee9a8b] VM_SerialGCCollect::doit+0x3b (serialVMOperations.cpp:39)
V [jvm.dll+0x10f63d7] VM_Operation::evaluate+0xd7 (vmOperations.cpp:75)
V [jvm.dll+0x10f8163] VMThread::evaluate_operation+0xe3 (vmThread.cpp:285)
V [jvm.dll+0x10f8877] VMThread::inner_execute+0x247 (vmThread.cpp:424)
V [jvm.dll+0x10f8e84] VMThread::run+0x114 (vmThread.cpp:177)
V [jvm.dll+0x1049e32] Thread::call_run+0x1b2 (thread.cpp:248)
V [jvm.dll+0xdf2481] thread_native_entry+0xe1 (os_windows.cpp:562)
C [ucrtbase.dll+0x2268a] (no source info available)
C [KERNEL32.DLL+0x17ac4] (no source info available)
C [ntdll.dll+0x5a8c1] (no source info available)
Taking the linux trace - this line:
V [libjvm.so+0x1660be0] SerialHeap::do_full_collection(bool)+0x394 (serialHeap.cpp:615)
maps to:
SerialFullGC::invoke_at_safepoint(clear_all_soft_refs);
which seems to somehow relate to the ParallelGC changes.
-
-
we see numerous tests crashing with Serial GC. E.g. on Linux:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000ffffb24938cc, pid=3372634, tid=3372642
#
# JRE version: Java(TM) SE Runtime Environment (26.0+10) (fastdebug build 26-ea+10-945)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+10-945, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x16538cc] Compacter::phase2_calculate_new_addr()+0x13ac
Current thread (0x0000ffffac0e3aa0): VMThread "VM Thread" [id=3372642, stack(0x0000ffff94531000,0x0000ffff9472f000) (2040K)]
Stack: [0x0000ffff94531000,0x0000ffff9472f000], sp=0x0000ffff9472cb00, free space=2030k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x16538cc] Compacter::phase2_calculate_new_addr()+0x13ac (klass.hpp:290)
V [libjvm.so+0x164fe1c] SerialFullGC::invoke_at_safepoint(bool)+0x25c (serialFullGC.cpp:725)
V [libjvm.so+0x1660be0] SerialHeap::do_full_collection(bool)+0x394 (serialHeap.cpp:615)
V [libjvm.so+0x9439f4] CollectedHeap::collect_as_vm_thread(GCCause::Cause)+0xb0 (collectedHeap.cpp:371)
V [libjvm.so+0xd2f93c] VM_CollectForMetadataAllocation::doit()+0xb8 (gcVMOperations.cpp:242)
V [libjvm.so+0x18e9090] VM_Operation::evaluate()+0x148 (vmOperations.cpp:74)
V [libjvm.so+0x190b4ec] VMThread::evaluate_operation(VM_Operation*)+0x52c (vmThread.cpp:284)
V [libjvm.so+0x190beec] VMThread::inner_execute(VM_Operation*)+0x3ec (vmThread.cpp:421)
V [libjvm.so+0x190c150] VMThread::loop()+0x88 (vmThread.cpp:487)
V [libjvm.so+0x190c284] VMThread::run()+0xa4 (vmThread.cpp:177)
V [libjvm.so+0x17fa02c] Thread::call_run()+0xac (thread.cpp:243)
V [libjvm.so+0x14da99c] thread_native_entry(Thread*)+0x12c (os_linux.cpp:868)
C [libc.so.6+0x80b50] start_thread+0x300
Windows crashes in a slightly deeper place:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff8f66cb43b, pid=8888, tid=1688
#
# JRE version: Java(TM) SE Runtime Environment (26.0+10) (fastdebug build 26-ea+10-942)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+10-942, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, windows-amd64)
# Problematic frame:
# V [jvm.dll+0x2ab43b] oopDesc::size_given_klass+0x1b
#
--------------- T H R E A D ---------------
Current thread (0x000002314a644420): VMThread "VM Thread" [id=1688, stack(0x000000b1c8400000,0x000000b1c8500000) (1024K)]
Stack: [0x000000b1c8400000,0x000000b1c8500000], sp=0x000000b1c84ff230, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x2ab43b] oopDesc::size_given_klass+0x1b (oop.inline.hpp:191)
V [jvm.dll+0xedc596] Compacter::phase2_calculate_new_addr+0x616 (serialFullGC.cpp:309)
V [jvm.dll+0xedaa24] SerialFullGC::invoke_at_safepoint+0x334 (serialFullGC.cpp:725)
V [jvm.dll+0xee6a05] SerialHeap::do_full_collection+0x1d5 (serialHeap.cpp:617)
V [jvm.dll+0xee66ea] SerialHeap::collect_at_safepoint+0x6a (serialHeap.cpp:557)
V [jvm.dll+0xee9a8b] VM_SerialGCCollect::doit+0x3b (serialVMOperations.cpp:39)
V [jvm.dll+0x10f63d7] VM_Operation::evaluate+0xd7 (vmOperations.cpp:75)
V [jvm.dll+0x10f8163] VMThread::evaluate_operation+0xe3 (vmThread.cpp:285)
V [jvm.dll+0x10f8877] VMThread::inner_execute+0x247 (vmThread.cpp:424)
V [jvm.dll+0x10f8e84] VMThread::run+0x114 (vmThread.cpp:177)
V [jvm.dll+0x1049e32] Thread::call_run+0x1b2 (thread.cpp:248)
V [jvm.dll+0xdf2481] thread_native_entry+0xe1 (os_windows.cpp:562)
C [ucrtbase.dll+0x2268a] (no source info available)
C [KERNEL32.DLL+0x17ac4] (no source info available)
C [ntdll.dll+0x5a8c1] (no source info available)
Taking the linux trace - this line:
V [libjvm.so+0x1660be0] SerialHeap::do_full_collection(bool)+0x394 (serialHeap.cpp:615)
maps to:
SerialFullGC::invoke_at_safepoint(clear_all_soft_refs);
which seems to somehow relate to the ParallelGC changes.
- caused by
-
JDK-8364176 Serial: Group all class unloading logic at the end of marking phase
-
- Resolved
-
- duplicates
-
JDK-8364504 [BACKOUT] JDK-8364176 Serial: Group all class unloading logic at the end of marking phase
-
- Resolved
-
- relates to
-
JDK-8364516 Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint
-
- Resolved
-