AOT Support for Method Handles (OpenJDK Implementation)

[dsouzai]

This issue describes a staged approach to enable AOT support for Method Handles (MH) for the OpenJDK Implementation (JDK17+); only AOT w/ SVM will/can be supported.

1. Unresolved Dispatch

Unresolved dispatch involves performing a resolved interpreter dispatch using a dummy linkToStatic method as the target method. For AOT, this requires only validating the polymorphic signature of the dummy linkToStatic method; the rest is handled by the resolved interpreter dispatch infrastructure which is already handled with the SVM.

• Add SVM Specific Options eclipse-omr/omr#7475
• Add SVM AOT support for unresolved invokeHandle/invokeDynamic dispatch #20272

2. Resolved Dispatch

• Add infrastructure to support relocatable compilations of the invokeHandle/invokeDynamic bytecodes eclipse-omr/omr#7494
• Add SVM AOT support for resolved invokeHandle/invokeDynamic dispatch #20373

Resolved dispatch is considerably more involved, and has a few more requirements:

1. Add ability to store the generated LambdaForm class into the SCC
2. Add validation record for invokeHandle/invokeDynamic
   • Store class chain of the class of the target method from member name
   • Remember method index (into the target method's class) of the target method
     • This is to to compare the method name indirectly; if the class chain validation succeeds, then the method index will refer to the same method name and bytecodes.
   • Remember whether the appendixObject is NULL or not

3. KOT enabled optimization

Resolved dispatch by itself isn't sufficient to generate optimal code; the compiler needs the Known Object Table (KOT) to "see through" a potential chain of method handles to be able to properly optimize. Thus, the AOT support will need to be added for the KOT. This can be implemented in a fairly straightforward approach using the SVM.

[dsouzai]

fyi @mpirvu @vijaysun-omr