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