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