JDK-8305509 : C1 fails "assert(k != nullptr) failed: illegal use of unloaded klass"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64,aarch64
  • Submitted: 2023-04-04
  • Updated: 2023-09-14
  • Resolved: 2023-04-04
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 21
21 b17Fixed
Related Reports
Relates :  
Description
The following test failed in the JDK21 CI:

applications/runthese/RunThese30M.java

Here's a snippet from the hs_err_pid file:

#  Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S20155/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/25a896f2-6f80-4034-93bb-7731ae83c590/runs/06507dd6-84d5-4d83-a568-765143c1c813/workspace/open/src/hotspot/share/ci/ciKlass.hpp:60), pid=1806559, tid=1806576
#  assert(k != nullptr) failed: illegal use of unloaded klass
#
# JRE version: Java(TM) SE Runtime Environment (21.0+17) (fastdebug build 21-ea+17-LTS-1381)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-ea+17-LTS-1381, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x892d1e]  ciKlass::get_Klass() const [clone .isra.0]+0x3e

<snip>

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

Current thread (0x00007f8c58268580):  JavaThread "C1 CompilerThread0" daemon [_thread_in_vm, id=1806576, stack(0x00007f8c22d6a000,0x00007f8c22e6b000)]


Current CompileTask:
C1: 726879 80201    b  3       com.sun.tck.lib.tgf.LeafIterator::<init> (73 bytes)

Stack: [0x00007f8c22d6a000,0x00007f8c22e6b000],  sp=0x00007f8c22e68850,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x892d1e]  ciKlass::get_Klass() const [clone .isra.0]+0x3e  (ciKlass.hpp:60)
V  [libjvm.so+0x894d3a]  ciEnv::get_klass_by_name_impl(ciKlass*, constantPoolHandle const&, ciSymbol*, bool)+0x1aa  (ciEnv.cpp:512)
V  [libjvm.so+0x895445]  ciEnv::get_klass_by_name(ciKlass*, ciSymbol*, bool)+0x1c5  (ciEnv.cpp:569)
V  [libjvm.so+0x8e464b]  ciObjectFactory::get_unloaded_klass(ciKlass*, ciSymbol*, bool)+0x5bb  (ciObjectFactory.cpp:503)
V  [libjvm.so+0x8da65d]  ciObjArrayKlass::make_impl(ciKlass*)+0x20d  (ciEnv.hpp:249)
V  [libjvm.so+0x8da950]  ciObjArrayKlass::make(ciKlass*) [clone .part.0]+0xd0  (ciObjArrayKlass.cpp:167)
V  [libjvm.so+0x7894b3]  LIRGenerator::do_NewObjectArray(NewObjectArray*)+0x163  (c1_LIRGenerator_x86.cpp:1356)
V  [libjvm.so+0x7678f3]  LIRGenerator::do_root(Instruction*)+0x63  (c1_LIRGenerator.cpp:374)
V  [libjvm.so+0x76bf1e]  non-virtual thunk to LIRGenerator::block_do(BlockBegin*)+0x5e  (c1_LIRGenerator.cpp:371)
V  [libjvm.so+0x731891]  BlockList::iterate_forward(BlockClosure*)+0x41  (c1_Instruction.cpp:889)
V  [libjvm.so+0x6f4bf6]  Compilation::emit_lir()+0x566  (c1_Compilation.cpp:258)
V  [libjvm.so+0x6f761f]  Compilation::compile_java_method()+0x32f  (c1_Compilation.cpp:404)
V  [libjvm.so+0x6f7f39]  Compilation::compile_method()+0x179  (c1_Compilation.cpp:473)
V  [libjvm.so+0x6f86d6]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x306  (c1_Compilation.cpp:600)
V  [libjvm.so+0x6fa02e]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xde  (c1_Compiler.cpp:258)
V  [libjvm.so+0x9ce470]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xaf0  (compileBroker.cpp:2265)
V  [libjvm.so+0x9cf338]  CompileBroker::compiler_thread_loop()+0x608  (compileBroker.cpp:1944)
V  [libjvm.so+0xe9d4de]  JavaThread::thread_main_inner()+0x17e  (javaThread.cpp:717)
V  [libjvm.so+0x17669b8]  Thread::call_run()+0xb8  (thread.cpp:224)
V  [libjvm.so+0x1469b0a]  thread_native_entry(Thread*)+0x11a  (os_linux.cpp:740)


Comments
Given that RunThese30M doesn't show up the problem anymore and that the fix is just a revert of a previous refactoring, I consider the it verified.
12-07-2023

The fix for this bug is integrated in jdk-21+17-1396.
04-04-2023

Changeset: 2ee42451 Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2023-04-04 16:31:21 +0000 URL: https://git.openjdk.org/jdk/commit/2ee42451057455fdfe7c102d7a341136999e16ef
04-04-2023

ILW = C1 assertion failure, multiple tests in tier4, no workaround = HLH = P2
04-04-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13327 Date: 2023-04-04 14:32:42 +0000
04-04-2023

[~coleenp] - It might be a coincidence, but jdk-21+17-1381-tier4 includes the fix for: JDK-8304743 Compile_lock and SystemDictionary updates and since C1 compiler thread is accessing an unloaded class...
04-04-2023

I added the get_Klass() that it's complaining about so I could handle-ize class_loader and protection domain in the utility function.
04-04-2023