RFR: 8312909: C1 should not inline through interface calls with non-subtype receiver
Tobias Hartmann
thartmann at openjdk.org
Tue Jul 25 12:57:12 UTC 2023
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 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
-------------
Commit messages:
- Removed trailing whitespace
- Updated bug number
- C1 should not inline through interface calls with non-subtype receiver
Changes: https://git.openjdk.org/jdk/pull/15018/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15018&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8312909
Stats: 109 lines in 3 files changed: 105 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/jdk/pull/15018.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/15018/head:pull/15018
PR: https://git.openjdk.org/jdk/pull/15018
More information about the hotspot-compiler-dev
mailing list