Integrated: 8312909: C1 should not inline through interface calls with non-subtype receiver

Tobias Hartmann thartmann at openjdk.org
Thu Aug 3 11:05:44 UTC 2023


On Tue, 25 Jul 2023 12:47:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This is a problem with C1 compiling an interface call with an invalid receiver (see `TestInvokeinterfaceWithBadReceiverHelper`):
> ``` 
>     ldc	String "42";
>     invokeinterface	InterfaceMethod MyInterface.get:"()Ljava/lang/String;",  1;
> 
> 
> `String` does not implement `MyInterface` but Class Hierarchy Analysis determined that there is only one implementor of MyInterface:
> 
> class MyClass implements MyInterface {
>     @Stable
>     String field = "42";
> 
>     public String get() {
>         return field;
>     }    
> }
> 
> C1 emits a receiver subtype check (that will obviously fail at runtime and trigger an `IncompatibleClassChangeError`) and proceeds with inlining the `MyClass::get` method on the `String` receiver. It then tries to fold a stable field load by loading it's value at compile time which asserts/fails because the `String` receiver does not have such a field. The fix is to bail out from inlining when we can statically determine that the receiver subtype check will always fail at runtime.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: ab1c212a
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab1c212ac1097ae6e1122ef1aba47ca51eca11f2
Stats:     109 lines in 3 files changed: 105 ins; 0 del; 4 mod

8312909: C1 should not inline through interface calls with non-subtype receiver

Reviewed-by: kvn, chagedorn

-------------

PR: https://git.openjdk.org/jdk/pull/15018


More information about the hotspot-compiler-dev mailing list