JDK-6766644 : Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs10,hs17,6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-11-03
  • Updated: 2016-06-20
  • Resolved: 2011-03-08
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 7 Other
7Fixed hs21Fixed
Related Reports
Relates :  
JDK-7024234 - jvmti tests fail assert(!_oops_are_stale) failed: oops are stale on Win-AMD64
Relates :  
JDK-6890958 - Intermittent NPE when calling a method after class redefinition
Relates :  
JDK-7030041 - deferred CompiledMethodLoad events may have a stale oop problem
Relates :  
JDK-7024970 - assert(ServiceThread::is_service_thread(Thread::current())) failed: Service thread must post enqueue
Description
Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" when running with fastdebug jvm:

# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/BUILD_AREA/jdk6_11/hotspot/src/share/vm/classfile/systemDictionary.cpp:211), pid=16154
, tid=7
#  Error: assert(!__the_thread__->is_Compiler_thread(),"Can not load classes with the Compiler thread")
#
# Java VM: Java HotSpot(TM) Client VM (11.0-b15-fastdebug mixed mode solaris-sparc)
nsk.jvmti.scenarios.hotswap.HS203.hs203t004.hs203t004
nsk/jvmti/scenarios/hotswap/HS203/hs203t004
Added here in the hope that the nightly failures summary will classify this
correctly as a (long) known failure, rather than as sometimes seems to happen
as a new failure.

#  Internal Error (/tmp/jprt/P1/B/185041.ysr/source/src/share/vm/classfile/systemDictionary.cpp:164), pid=8408, tid=11
#  assert(!THREAD->is_Compiler_thread()) failed: Can not load classes with the Compiler thread
#
# JRE version: 7.0
# Java VM: OpenJDK 64-Bit Server VM (20.0-b02-201011111850.ysr.assert-fastdebug mixed mode solaris-sparc compressed oops)
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bf8517f4e4d0
04-02-2011
EVALUATION This is quite the conundrum. According to the current JVM/TI spec, it is quite legal for the CompiledMethodLoad event handler to call RedefineClasses(). There are a few restrictions on other event handlers and the APIs that they can call, but I can find no relevant restrictions in this particular case. In HotSpot, the CompilerThread is subclassed from a JavaThread and is_hidden_from_external_view() returns true. The CompiledMethodLoad event itself doesn't provide any thread info or context. So if we can figure out how to have a different JavaThread proxy the event posting, then that might be a workable solution. The problem is determining the "right" JavaThread to do the work. If I understand how the JIT stuff works, the JavaThread that is executing the bytecode that the CompilerThread is compiling is not just waiting around for the CompilerThread to finish the compilation so we can't just "borrow" that thread's context for an event posting. And we can't just pick a JavaThread at random since class loading has context associated with it. I need to take a closer look at RedefineClasses() and the context in which it operates.
11-01-2011
EVALUATION The is happens because the JVMTI notification is performed from the compiler thread and the agent calls back in to redefine some classes which causes class loading and that's not allowed in the compiler thread. here's the stack trace: [1] report_assertion_failure(file_name = 0xfed3392f "/net/smite.sfbay/export/ws/baseline/src/share/vm/classfile/systemDictionary.cpp", line_no = 155, message = 0xfed3397f "assert(!__the_thread__->is_Compiler_thread(),"Can not load classes with the Compiler thread")"), line 171 in "debug.cpp" =>[2] SystemDictionary::resolve_or_null(class_name = CLASS, class_loader = CLASS, protection_domain = CLASS, __the_thread__ = 0x144000), line 155 in "systemDictionary.cpp" [3] SystemDictionary::resolve_super_or_fail(child_name = CLASS, class_name = CLASS, class_loader = CLASS, protection_domain = CLASS, is_superclass = true, __the_thread__ = 0x144000), line 310 in "systemDictionary.cpp" [4] ClassFileParser::parseClassFile(this = 0xf347e3f0, name = CLASS, class_loader = CLASS, protection_domain = CLASS, host_klass = CLASS, cp_patches = (nil), parsed_name = CLASS, verify = true, __the_thread__ = 0x144000), line 2785 in "classFileParser.cpp" [5] SystemDictionary::parse_stream(class_name = CLASS, class_loader = CLASS, protection_domain = CLASS, st = 0xf347e648, host_klass = CLASS, cp_patches = (nil), __the_thread__ = 0x144000), line 967 in "systemDictionary.cpp" [6] SystemDictionary::parse_stream(class_name = CLASS, class_loader = CLASS, protection_domain = CLASS, st = 0xf347e648, __the_thread__ = 0x144000), line 251 in "systemDictionary.hpp" [7] VM_RedefineClasses::load_new_class_versions(this = 0xf347e898, __the_thread__ = 0x144000), line 863 in "jvmtiRedefineClasses.cpp" [8] VM_RedefineClasses::doit_prologue(this = 0xf347e898), line 80 in "jvmtiRedefineClasses.cpp" [9] VMThread::execute(op = 0xf347e898), line 539 in "vmThread.cpp" [10] JvmtiEnv::RedefineClasses(this = 0x28438, class_count = 1, class_definitions = 0xf347ea38), line 254 in "jvmtiEnv.cpp" [11] jvmti_RedefineClasses(env = 0x2843c, class_count = 1, class_definitions = 0xf347ea38), line 3802 in "jvmtiEnter.cpp" [12] nsk_jvmti_redefineClass(0x2843c, 0x1c0c10, 0xff2f3364, 0xfffed8d4, 0xfe63cdc0, 0x12400), at 0xfddbbf1c [13] callbackCompiledMethodLoad(0x2843c, 0xfddda6fc, 0xfffee6cc, 0xfddd7dac, 0xfffee64c, 0x11800), at 0xfddbc800 [14] JvmtiExport::post_compiled_method_load(nm = 0xfbd12048), line 1758 in "jvmtiExport.cpp" [15] nmethod::post_compiled_method_load_event(this = 0xfbd12048), line 1408 in "nmethod.cpp" [16] ciEnv::register_method(this = 0xf347f8a0, target = 0xfe390, entry_bci = -1, offsets = 0xf347f6dc, orig_pc_offset = 112, code_buffer = 0xf347f6f8, frame_words = 30, oop_map_set = 0x16d5b0, handler_table = 0xf347f6b0, inc_table = 0xf347f6c4, compiler = 0x1406b0, comp_level = 2, has_debug_info = true, has_unsafe_access = false), line 981 in "ciEnv.cpp" [17] Compilation::install_code(this = 0xf347f680, frame_size = 30), line 293 in "c1_Compilation.cpp" [18] Compilation::compile_method(this = 0xf347f680), line 347 in "c1_Compilation.cpp" [19] Compilation::Compilation(this = 0xf347f680, compiler = 0x1406b0, env = 0xf347f8a0, method = 0xfe390, osr_bci = -1), line 442 in "c1_Compilation.cpp" [20] Compiler::compile_method(this = 0x1406b0, env = 0xf347f8a0, method = 0xfe390, entry_bci = -1), line 73 in "c1_Compiler.cpp" [21] CompileBroker::invoke_compiler_on_method(task = 0x173af0), line 1543 in "compileBroker.cpp" [22] CompileBroker::compiler_thread_loop(), line 1389 in "compileBroker.cpp" [23] compiler_thread_entry(thread = 0x144000, __the_thread__ = 0x144000), line 2741 in "thread.cpp" [24] JavaThread::thread_main_inner(this = 0x144000), line 1381 in "thread.cpp" [25] JavaThread::run(this = 0x144000), line 1365 in "thread.cpp" [26] java_start(thread_addr = 0x144000), line 1019 in "os_solaris.cpp" I think the doit_prologue needs operate differently if it is in a compiler thread or maybe the notification should be performed from another thread.
14-10-2009