United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6766644 Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"
JDK-6766644 : Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"

Details
Type:
Bug
Submit Date:
2008-11-03
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
generic
Sub-Component:
jvmti
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs10,hs17
Fixed Versions:
hs21 (b02)

Related Reports
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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

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.
                                     
2009-10-14
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.
                                     
2011-01-11
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bf8517f4e4d0
                                     
2011-02-04



Hardware and Software, Engineered to Work Together