JDK-6790209 : fastdebug server VM fails with assertion "_new: typeflow responsibility"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs14
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2009-01-05
  • Updated: 2011-03-08
  • 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 6 JDK 7 Other
6u18Fixed 7Fixed hs15Fixed
Related Reports
Relates :  
JDK-4474172 - JavaWebServer can not be started with B69
Description
fastdebug server VM fails with assertion
#  Internal Error (/tmp/jprt/P1/B/180300.et151817/source/src/share/vm/opto/parseHelper.cpp:206), pid=19334, tid=1089567040
#  Error: assert(will_link,"_new: typeflow responsibility")
Comments
EVALUATION The fix has been verified as part of hs15-b02 pit.
24-02-2009
PUBLIC COMMENTS CI uses non-blocking system dictionary check by calling SystemDictionary::find() method which does not have the fix for reflection class loader (4474172) used by Interpreter to resolve a class in the method SystemDictionary::resolve_instance_class_or_null(). Solution: Add missing code.
16-01-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/48bb4a49b7ac
16-01-2009
EVALUATION The problem is the method's holder has a non-default loader and there is _new bytecode executed in interpreter which uses the klass (resolved and loaded) with default loader and there are other not yet executed _new bytecodes with the same klass name (unresolved). ciEnv::get_klass_by_index_impl() has the check at the end for prior unloaded klass: check_get_unloaded_klass(accessor, name). The unloaded klass list is empty when ciTypeFlow processes first _new bytecode so it uses the klass with default loader returned from constantPoolOopDesc::klass_at_if_loaded(cpool, index). Later when ciTypeFlow processes unresolved klasses with the same name it populates the unloaded klass list with the klass which has the same loader as the method's holder since SystemDictionary can't find it (the method's holder loader and protection_domain is used for search, see ciEnv::get_klass_by_name_impl()). Later during parsing phase Parse::do_new() calls ciEnv::get_klass_by_index_impl() again for the first _new klass. But this time unloaded klass list is not empty so check_get_unloaded_klass(accessor, name) returns unloaded klass which causes the bug's assert. The reason CiEnv can't find the same class is it uses non-blocking system dictionary check SystemDictionary::find() which does not have the fix for reflection class loader (4474172) Iinterpreter use SystemDictionary::resolve_instance_class_or_null() which has special code for reflaction class loader before the call to find(): class_loader = Handle(THREAD, java_lang_ClassLoader::non_reflection_class_loader(class_loader()));
15-01-2009