Support for OpenJDK LambdaForm

[babsingh]

1. Add new JCL flag: OPENJDK_METHODHANDLES

A new JCL flag, OPENJDK_METHODHANDLES, is introduced to enable/disable
support for OpenJDK MethodHandles. Currently, it is declared in an
unused set so that it stays disabled.

2. Enable OpenJDK LambdaForm

Supporting OpenJDK LambdaForm is the next step in adopting OpenJDK
MethodHandles.

Few OpenJ9 classes are disabled. This enables the OpenJDK variant of
those classes. The newly enabled OpenJDK classes are used to support
OpenJDK LambdaForm.

3. Add field/method stubs to support the compilation of OpenJDK LambdaForm

4. Update enum VarHandle.AccessType to work with OpenJDK LambdaForm

Note: OpenJ9 VarHandle will be replaced with OpenJDK VarHandle once
OpenJDK MethodHandles are adopted by OpenJ9.

5. Support VarHandle(VarForm ...) constructor with OpenJDK MemberName

• VarHandle(VarForm ...) supported without version restriction
• OpenJDK VarForm always enabled
• VarHandle(VarForm ...) supported with OpenJ9 and OpenJDK MemberName
• Key methods implemented in OpenJ9 MemberName to support VarHandle

6. Support VarHandle with OpenJDK and OpenJ9 MethodType

MethodType.dropFirstParameterType not available in OpenJDK MethodType.

Related: #7352, #9456

Co-authored-by: Jack Lu Jack.S.Lu@ibm.com
Signed-off-by: Babneet Singh sbabneet@ca.ibm.com

[babsingh]

@fengxue-IS ...

• This PR depends on the OpenJDK MemberName and MethodType changes: https://github.com/fengxue-IS/openj9/commits/avacadoinvoke.
• You will need to rebase MemberName and VarHandle.
• The new JCL flag is named OPENJDK_METHODHANDLES. You can add a similar native flag in j9cfg.h.in for the VM and JIT changes.
• JEP370 in JDK14 depends on the native functions in MemberName and MethodHandleNatives. You can use JEP370 to test your implementation of those native functions.
• I will work on the invokebasic bytecode, next.

[babsingh]

@DanHeidinga I have drafted these changes so that they can be merged. Ultimately, all the new code introduced in this pull request can be removed/disabled once the OpenJDK MethodHandles are adopted.

[babsingh]

@DanHeidinga Conflicts have been resolved, and IF defs have been re-added. This PR is ready to be reviewed/merged.

I had removed the IF defs to adopt all the OpenJDK VarHandles across Java11+ using the OpenJ9 VarHandle class. I wanted to extend the JEP370 work, where we added support for MemoryAddressViewVarHandles, to all OpenJDK VarHandles. This will allow us to get rid of the OpenJ9 VarHandles. Some work/issues are still pending to achieve this goal. I will remove the IF defs once we are ready to consume all OpenJDK VarHandles. This work is low priority, and won't be pursued until OpenJDK MethodHandles are adopted.

[pshipton]

@babsingh is this still relevant?

[babsingh]

is this still relevant?

yes, i am waiting for someone to merge these changes.

[babsingh]

@gacholio can you please review these changes? these changes are for adopting OpenJDK MethodHandles.

[gacholio]

Why are these changes necessary? Are we not replacing the entire MH hierarchy in which case just ifdef out all of our classes.

[babsingh]

Why are these changes necessary? Are we not replacing the entire MH hierarchy in which case just ifdef out all of our classes.

We still keep OpenJ9 VarHandles. Some of these changes allow OpenJ9 VarHandles to work with OpenJDK MemberName.

This work was done incrementally. So, this PR was created (2 months ago) after the LambdaForm checkpoint was reached. The remaining MH hierarchy is disabled here: #10094, which was created 2 weeks ago. After this PR is merged, I will be rebasing #10094 along with a request for it to be merged.

[gacholio]

jenkins test sanity,extended zlinux jdk11

[gacholio]

@babsingh Can you see what's wrong here?

[babsingh]

Only one failure was seen in Test_openjdk11_j9_extended.functional_s390x_linux_Personal:

03:44:50  SoftMxTest: Softmx OOM Callback triggered, adjusted softmx up to avoid OOM:536870912
03:44:50  FAILED: testExpandHeapUntilOOM
03:44:50  java.lang.OutOfMemoryError: Java heap space
03:44:50  	at org.testng.internal.Invoker.invokeMethod(Invoker.java:610)
03:44:50  	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:716)
03:44:50  	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:988)
...

@gacholio This failure is unrelated to my changes since it is also happening elsewhere, #10189.