RFR(XL): 6312651: Compiler should only use verified interface types for optimization

[Vladimir Ivanov]

It seems the trick here is the rebase I did. I failed to link the 
failures I see to the rebase changes, but, please, double-check I didn't 
break anything.

I use the following changes on top of your patch:
   http://cr.openjdk.java.net/~vlivanov/roland/6312651/rebase.00/

$ hg log -r qparent
changeset:   55511:91b38bfb9079
tag:         qparent
user:        aoqi
date:        Thu Jun 27 18:00:54 2019 +0800
summary:     8226871: invalid use of incomplete type class 
MacroAssembler when building minimal after JDK-8191278


>> (2) Numerous test failures:
>> #  Internal Error (src/hotspot/share/opto/type.cpp:3696), pid=75399,
>> tid=43267
>> #  assert(!ik->is_interface()) failed: no interface here
> 
> Does it fail that way with a test I can run?

For example, gc/epsilon/TestArraycopyCheckcast.java

#  Internal Error 
(/Users/vlivanov/ws/jdk/open/jdk/src/hotspot/share/opto/type.cpp:3696), 
pid=49533, tid=16387
#  assert(!ik->is_interface()) failed: no interface here

Current CompileTask:
C2:   2313  321    b  4 
jdk.internal.module.SystemModuleFinders$SystemModuleFinder::<init> (21 
bytes)

V  [libjvm.dylib+0x11c23bb]  TypeInstPtr::make(TypePtr::PTR, ciKlass*, 
TypePtr::InterfaceSet const&, bool, ciObject*, int, int, TypePtr const*, 
int)+0x23b
V  [libjvm.dylib+0x11cb794] 
TypeOopPtr::make_from_klass_common(ciKlass*, TypePtr::InterfaceSet 
const&, bool, bool)+0x2e4
V  [libjvm.dylib+0x11cb87c] 
TypeOopPtr::make_from_klass_common(ciKlass*, TypePtr::InterfaceSet 
const&, bool, bool)+0x3cc
V  [libjvm.dylib+0x2e63ee]  TypeOopPtr::make_from_klass(ciKlass*)+0x3e
V  [libjvm.dylib+0x11be347]  Type::get_const_type(ciType*)+0x67
V  [libjvm.dylib+0x11c6393]  TypeTuple::make_domain(ciInstanceKlass*, 
ciSignature*)+0x173
V  [libjvm.dylib+0x11d8474]  TypeFunc::make(ciMethod*)+0x94
V  [libjvm.dylib+0x5d0947]  Compile::Compile(ciEnv*, C2Compiler*, 
ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xa37


>> (3) Unloaded classes in signatures trigger the following assert:
> 
> Same as above, can I reproduce it?

Unfortunately, the failing test is not part of open repository.
The test triggers an OSR compilation of a method with a unloaded method 
in its signature. As the stack trace shows, the assert is fired during 
interpreter state unpacking.

>> (4) runtime/Unsafe/AllocateInstance.java
>> java.lang.AssertionError: Should throw InstantiationException for an
>> interface
>> 	at AllocateInstance.testInterface(AllocateInstance.java:71)
>> 	at AllocateInstance.main(AllocateInstance.java:81)
>> 	at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> 	at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> 	at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
>> 	at
>> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>> 	at java.base/java.lang.Thread.run(Thread.java:830)
> 
> That one runs fine with no option or -Xcomp. Does it need any specific
> option to fail?

It fails reliably w/o any additional flags.

Best regards,
Vladimir Ivanov