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

[Roland Westrelin]

Hi Vladimir,

>>> (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

I still can't reproduce that one. Can you give me a short list of tests
that fail that way?

>>> (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.

I managed to write a test case from your description and can reproduce
it now.

>>> (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.

I can reproduce it now. It seems there's a bigger problem
though. Current C2 compiles the following method:

    private static void test3(Class klass) throws IllegalAccessException, InstantiationException {
        UNSAFE.allocateInstance(klass);
    }

without any allocation (EA removes it). Calling it with an interface:

test3(I.class);

then succeeds. So either we trust the unsafe user to know what she/he's
doing or we need a runtime check (that would also cover the failure you
reported with my patch). What do you think?

Roland.