United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6790209 fastdebug server VM fails with assertion "_new: typeflow responsibility"
JDK-6790209 : fastdebug server VM fails with assertion "_new: typeflow responsibility"

Details
Type:
Bug
Submit Date:
2009-01-05
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
linux
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs14
Fixed Versions:
hs15 (b02)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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 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()));
                                     
2009-01-15
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/48bb4a49b7ac
                                     
2009-01-16
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.
                                     
2009-01-16
EVALUATION

The fix has been verified as part of hs15-b02 pit.
                                     
2009-02-24



Hardware and Software, Engineered to Work Together