JDK-8280469 : No CHA for interface calls when inlining through method handle linker
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-01-21
  • Updated: 2022-12-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8275830 - C2: Receiver downcast is missing when inlining through method handle linkers
Relates :  
JDK-6986483 - CHA: optimize calls through interfaces
Relates :  
JDK-6312651 - Compiler should only use verified interface types for optimization
Relates :  
JDK-8297933 - [REDO] Compiler should only use verified interface types for optimization
Description
CHA can devirtualize interface calls by strength reducing them to virtual calls when there's only a single direct implementor class present at runtime. 

It relies on symbolic information present in bytecode and doesn't work when invocation goes through method handle linker (MethodHandle.linkToInterface()):

src/hotspot/share/opto/doCall.cpp:

    if (call_does_dispatch && bytecode == Bytecodes::_invokeinterface) {
      ciInstanceKlass* declared_interface =
          caller->get_declared_method_holder_at_bci(bci)->as_instance_klass();
      ciInstanceKlass* singleton = declared_interface->unique_implementor();

(Both C1 and C2 are affected.)
Comments
cha_intf_mh_test.patch enhances test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java with method handle invocation mode.
21-01-2022
Method handle linkers rely on MemberName (passed as an appendix argument) to perform method selection. Resolved MemberName contains all necessary information needed, but CHA needs symbolic class information (REFC). Symbolic information is lost during MemberName resolution and receiver subtype check is performed in java.lang.invoke code instead before calling into MH linker. Until C2 trusts interface types, there's no way to reliably recover that type information and the only possible solution is to reify REFC in the MemberName instance during resolution to make it accessible to JIT-compilers during compilation.
21-01-2022