[JDK11] Fix AccessControlException in resolveInvokeDynamic

[babsingh]

MethodHandleResolver.resolveInvokeDynamic (linkage) relies upon
MethodType.fromMethodDescriptorString to derive the MethodType from
the method descriptor string.

Enabling OJDK's MethodType.fromMethodDescriptorString in OpenJ9 JDK11
causes an AccessControlException, which makes it unsuitable for usage
during linkage.

resolveInvokeDynamic (linkage) can employ its own approach to derive
the MethodType from the method descriptor string.

To resolve the AccessControlException, a helper method is derived from
OJ9's MethodType.fromMethodDescriptorString, and it is utilized in
MethodHandleResolver.

The helper also enables a Map based cache per ClassLoader in both
implementations. Currently, the cache is only available in OJ9 MHs.

Related: #14555

[babsingh]

@JasonFengJ9 Requesting your review. I have just moved the code around ... didn't put much effort in getting consistent formatting.

[JasonFengJ9]

From a stacktrace captured when running java/lang/System/LoggerFinder/internal/BasePlatformLoggerTest/BasePlatformLoggerTest.java

	at java.base/java.lang.invoke.MethodTypeHelper.nonPrimitiveClassFromString(MethodTypeHelper.java:187)
	at java.base/java.lang.invoke.MethodTypeHelper.parseIntoClass(MethodTypeHelper.java:222)
	at java.base/java.lang.invoke.MethodTypeHelper.parseIntoClasses(MethodTypeHelper.java:286)
	at java.base/java.lang.invoke.MethodTypeHelper.fromMethodDescriptorStringInternal(MethodTypeHelper.java:333)
	at java.base/java.lang.invoke.MethodTypeHelper.vmResolveFromMethodDescriptorString(MethodTypeHelper.java:365)
	at java.base/java.lang.invoke.MethodHandleResolver.resolveInvokeDynamic(MethodHandleResolver.java:169)
	at app//BasePlatformLoggerTest.testLogger(BasePlatformLoggerTest.java:545)
	at app//BasePlatformLoggerTest.test(BasePlatformLoggerTest.java:474)
	at app//BasePlatformLoggerTest.lambda$main$0(BasePlatformLoggerTest.java:406)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
	at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:497)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:487)
	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:239)
	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
	at app//BasePlatformLoggerTest.main(BasePlatformLoggerTest.java:378)

The code path is

openj9/jcl/src/java.base/share/classes/java/lang/invoke/MethodTypeHelper.java

Line 211 in 7463bc9

return Class.forName(name, false, classLoader);

Is this the same as OpenJ9 JDK11 default mode which was concerned at

• Fix AccessControlException in MT.fromMethodDescriptorString method ibmruntimes/openj9-openjdk-jdk11#680 (comment)

[babsingh]

Is this the same as OpenJ9 JDK11 default mode which was concerned at ibmruntimes/openj9-openjdk-jdk11#680 (comment)?

No.

• Fix AccessControlException in MT.fromMethodDescriptorString method ibmruntimes/openj9-openjdk-jdk11#680 modified the implementation of MethodType.fromMethodDescriptorString and didn't satisfy the Javadoc requirements to utilize ClassLoader.loadClass.
• In this PR, vmResolveFromMethodDescriptorString is only used internally within MethodHandleResolver for linkage when OJDK MHs are enabled. No public method, governed by the Javadoc, is impacted when OJDK MHs are enabled.
• For OJ9 MHs, MethodType.fromMethodDescriptorString is updated to invoke the new helper but its functional behaviour is unchanged.

[JasonFengJ9]

LGTM

[JasonFengJ9]

@tajila could you review/merge?

[tajila]

jenkins test sanity alinux64 jdk11