[GR-23900] More support for JDK 15.

PullRequest: graal/6380
wincc0823 · Jun 3, 2020 · 746344a · 746344a
2 parents 8323778 + adea3a8
commit 746344a
Show file tree

Hide file tree

Showing 2 changed files with 21 additions and 2 deletions.
diff --git a/...aalvm.compiler.replacements/src/org/graalvm/compiler/replacements/MethodHandlePlugin.java b/...aalvm.compiler.replacements/src/org/graalvm/compiler/replacements/MethodHandlePlugin.java
@@ -111,6 +111,24 @@ public <T extends ValueNode> T add(T node) {
                 }
 
                 b.handleReplacedInvoke(invoke.getInvokeKind(), targetMethod, argumentsList.toArray(new ValueNode[argumentsList.size()]), inlineEverything);
+
+                /*
+                 * After handleReplacedInvoke, a return type according to the signature of
+                 * targetMethod has been pushed. That can be different than the type expected by the
+                 * method handle invoke. Since there cannot be any implicit type conversion, the
+                 * only safe option actually is that the return type is not used at all. If there is
+                 * any other expected return type, the bytecodes are wrong. The JavaDoc of
+                 * MethodHandle.invokeBasic states that this "could crash the JVM", so bailing out
+                 * of compilation seems like a good idea.
+                 */
+                JavaKind invokeReturnKind = invokeReturnStamp.getTrustedStamp().getStackKind();
+                JavaKind targetMethodReturnKind = targetMethod.getSignature().getReturnKind().getStackKind();
+                if (invokeReturnKind != targetMethodReturnKind) {
+                    b.pop(targetMethodReturnKind);
+                    if (invokeReturnKind != JavaKind.Void) {
+                        throw b.bailout("Cannot do any type conversion when invoking method handle, so return value must remain popped");
+                    }
+                }
             }
             return true;
         }

diff --git a/....svm.hosted/src/com/oracle/svm/hosted/phases/IntrinsifyMethodHandlesInvocationPlugin.java b/....svm.hosted/src/com/oracle/svm/hosted/phases/IntrinsifyMethodHandlesInvocationPlugin.java
@@ -342,12 +342,13 @@ public InlineInfo shouldInlineInvoke(GraphBuilderContext b, ResolvedJavaMethod m
             }
 
             String className = method.getDeclaringClass().toJavaName(true);
-            if (className.startsWith("java.lang.invoke.VarHandle")) {
+            if (className.startsWith("java.lang.invoke.VarHandle") && !className.equals("java.lang.invoke.VarHandle")) {
                 /*
                  * Do not inline implementation methods of various VarHandle implementation classes.
                  * They are too complex and cannot be reduced to a single invoke or field access.
                  * There is also no need to inline them, because they are not related to any
-                 * MethodHandle mechanism.
+                 * MethodHandle mechanism. Methods defined in VarHandle itself are fine and not
+                 * covered by this rule.
                  */
                 return null;
             } else if (className.startsWith("java.lang.invoke")) {