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()));
|
Java