Research replace MethodHandle class with OpenJDK implementation on JDK Next

[fengxue-IS]

Research the effect of using OpenJDK MethodHandle implementation in OpenJ9, this work requires update to existing code structure inorder to satisify the dependencies.

Prototyping with following changes:

• Replace MethodType class (Replace MethodType & MethodTypeForm with OpenJDK implementation #7625)
  • Replace MethodType & MethodTypeForm
  • Update vmconstantpool.xml references
  • Move OpenJ9 MethodType API to new MethodTypeHelper class
• JIT support for OpenJDK MethodType class
  • Update references to MethodType fields (JIT support for using OpenJDK MethodType class #7628)
  • Fix methodDescriptor assumption (Get method descriptor from ptypes and rtype #8066)
    • Currently assmue field is initialized during MethodType creation/intern
    • New case: only initalized after first call to MethodType.toMethodDescriptorString()
• support scanning CP during scavenges (Support non-tenured objects in the constantpool #7486)
• support ConstantPool patching (Support for CP String patching #8460)
  • sum.misc.Unsafe.defineAnonymousClass
  • refer to MauveMultiThreadLoadTest_0 NPE PropertyDescriptor.constructorTest2 #8396 for support non-String CP types
• support MemberName (WIP: Replace MemberName class with OpenJDK implementation #7680)
  • Needed by:
    • LambdaForm
    • MethodHandle
    • Invokers
• support LambdaForm
  • Requires:
    • BoundMethodHandle
    • InvokerBytecodeGenerator
    • LambdaFormEditor
• separate MH resolution code into new helper class
• support MHNatives.linkTo intrinsic
• Add an invokebasic bytecode based on @polymorphicSignature invokeBasic() method

Note:

1. resolution approaches for MH:
   • single slot result (memberName/appendix in Object[]) Update resolve code to support OpenJDK MH #10893
   • double slot sturct (single resolve thread/lock on appendix slot) Update resolvesupport.cpp to support OpenJDK MH #10762

TODO:

• Clean up of J9VM_OPT_METHODHANDLE flag

[pshipton]

@DanHeidinga I don't expect this will be finished for the 0.23 release, moving out.

[DanHeidinga]

Agreed. I think the tentative target is JDK16

[pshipton]

@fengxue-IS @babsingh @tajila since we shipped jdk17 with OpenJDK MH enbabled, it seems this should be closed. Is this still tracking anything we need to track, are we keeping it open until all versions have OpenJDK MH enabled? I'd like to at least move it forward to 0.32 unless there is something here that has to be completed for jdk18. If there is, perhaps a more specific issue is better.

[tajila]

We can make separate issues to track JDK11 and 8