Fold MethodHandle.asType in Lambdaform-generated methods by matthewhall2 · Pull Request #23481 · eclipse-openj9/openj9

matthewhall2 · 2026-03-10T19:53:26Z

When calling originalMH.invoke(args), MH.asType is called at runtime to ensure the arguments are compatible with the original MH. A MethodType for the arguments is constructed and checked against the original MethodHandle's MethodType. This is essentially subtype compatibility.
When the types do not match exactly (but are compatible), the LambdaForm needs to be edited to perform typecasts before making the call to the target, resulting in a new MethodHandle. This can result in substantial runtime overhead.

Const refs allows us to create a reference to the resulting new MethodHandle when it is known to be constant at compile time, and to simply use that reference instead of having to call asType on each invocation of the MethodHandle.

This PR:

Adds recognized method for Invokers.checkGenericType (the main callsite for MH.asType).
Folds call to the asTypeCache if the types are compatible and the asTypeCache is non-null.
- Adds const provenance edge from the original MethodHandle to the asTypeCache (the result of the asType) methodhandle.

(for calls like mh.invoke(args), mh is the original MethodHandle, and the result of the asType call is the target MethodHandle.)
Type checking each type in the MT in not needed. If the MT of the asTypeCache MH is the same as the MT of the target MH, we can just use the cached MH. If they are not the same, then we cannot fold since we have no way of obtaining the asType result at compile time. (we also should not even get here if they are not the same, since we shouldn't have a known-object for the target MT in that case).

nbhuiyan · 2026-03-12T19:54:14Z

runtime/compiler/env/j9method.cpp

        { x(TR::java_lang_invoke_MethodHandle_asType_instance, "asType",
         "(Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MethodHandle;") },
+        { x(TR::java_lang_invoke_Invokers_checkGenericType, "checkGenericType",
+         "(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MethodHandle;") },


This is not the right place to add this method. It is only for methods of class MethodHandle.

matthewhall2 · 2026-03-16T20:43:35Z

thanks @nbhuiyan . I realized there is a much simpler way of checking the type compatibility. See PR description.

nbhuiyan · 2026-03-18T20:00:59Z

runtime/compiler/env/VMJ9.cpp

+     */
+    TR::KnownObjectTable *knot = comp->getKnownObjectTable();
+    if (!knot)
+        return false;


Return 0 here similar to the return 0 at the end, as the return type of the function is uintptr_t.

nbhuiyan · 2026-03-18T20:03:32Z

runtime/compiler/env/VMJ9.cpp

+
+    /* We shouldn't need to check for anonymous classes or for same class loaders for the Hard Cache case.
+     * The java.lang.invoke infrastructure only sets this cache when it is safe to do so.
+     * TODO: if we find that the normal asTypeCache doesn't get many hits, add (careful) checks for the soft cache.å


Looks like some unintended character at the end of this line.

Also, I prefer not to add more TODO labels. The comment can be updated to describe the TODO as something to consider in the future.

nbhuiyan · 2026-03-18T20:14:40Z

runtime/compiler/env/VMJ9.cpp

+        return cachedMH;
+    }
+    return 0;
+}


VMAccess ends here, with the function returning a raw pointer (if successful). The callers of this function then takes the resulting raw pointer, and then calls knot->getOrCreateIndex(result of this function), which is not GC safe. The VM access should be held all the way till the knot index is obtained, and the easiest way to do that would be to modify this function to return the knot index instead of the raw pointer, so that VM access is held throughout.

nbhuiyan · 2026-03-18T20:16:25Z

runtime/compiler/optimizer/MethodHandleTransformer.hpp

     */
    void process_java_lang_invoke_Invokers_checkVarHandleGenericType(TR::TreeTop *tt, TR::Node *node);

+    void process_java_lang_invoke_MethodHandle_asType(TR::TreeTop *tt, TR::Node *node);


Add doxygen documentation

nbhuiyan · 2026-03-18T20:17:44Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

 #endif // TR_ALLOW_NON_CONST_KNOWN_OBJECTS
 }
+
+void TR_MethodHandleTransformer::process_java_lang_invoke_MethodHandle_asType(TR::TreeTop *tt, TR::Node *node)


This function should check if const resfs are enabled, without which it should abort.

nbhuiyan · 2026-03-18T20:36:13Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+    J9::ConstProvenanceGraph *cpg = comp()->constProvenanceGraph();
+    // cpg->addEdge(cpg->knownObject(idx), clazz);
+    auto knot = comp()->getKnownObjectTable();
+    bool transformed = false;


This will trigger unused variable warnings.

nbhuiyan · 2026-03-18T20:36:56Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+    logprintf(trace(), comp()->log(), "MethodHandle is obj%d\n", mhIndex);
+    logprintf(trace(), comp()->log(), "MethodType is obj%d\n", desiredMTIndex);
+    J9::ConstProvenanceGraph *cpg = comp()->constProvenanceGraph();
+    // cpg->addEdge(cpg->knownObject(idx), clazz);


We should not be adding commented out code.

nbhuiyan · 2026-03-18T20:38:32Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+        uintptr_t convertedMH = fej9->getConvertedMethodhandle(comp(), mhIndex, desiredMTIndex);
+        if (0 != convertedMH) {
+            logprintf(trace(), comp()->log(), "Method types are the compatible%d\n");
+            TR::KnownObjectTable::Index convertedMHIndex = knot->getOrCreateIndex(convertedMH);


Same issue as in InterpreterEmulator. It is not safe to call getOrCreateIndex with a raw pointer without VM access being held for the whole duration.

nbhuiyan · 2026-03-18T20:54:42Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+void TR_MethodHandleTransformer::process_java_lang_invoke_MethodHandle_asType(TR::TreeTop *tt, TR::Node *node)
+{
+    auto mhNode = node->getChild(0);
+    auto desiredMTNode = node->getChild(1);


Better to use node->getArgument instead of node->getChild when trying to access specific args of a call node, as otherwise we run into the risk of unintentionally accessing the receiver instead of the first arg. In this case, using getChild is not incorrect, but should ideally use getArgument.

nbhuiyan · 2026-03-18T20:56:24Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+        logprintf(trace(), comp()->log(), "Exact compatibilty check failed - checking subtype compatibility\n");
+        uintptr_t convertedMH = fej9->getConvertedMethodhandle(comp(), mhIndex, desiredMTIndex);
+        if (0 != convertedMH) {
+            logprintf(trace(), comp()->log(), "Method types are the compatible%d\n");


Typo, and a format specifier with no args to feed it.

0xdaryl · 2026-03-19T01:56:13Z

runtime/compiler/env/VMJ9.cpp

+uintptr_t TR_J9VMBase::getConvertedMethodhandle(TR::Compilation *comp, TR::KnownObjectTable::Index mhIndex,
+    TR::KnownObjectTable::Index desiredTypeIndex)
+{
+    /* Indidivual type compatibilty checks on each type in the MT are not needed. Since we only fold


sp: Individual

matthewhall2 · 2026-03-24T14:17:46Z

thanks @nbhuiyan , this is ready for another review

nbhuiyan

In addition to these review comments, please update JITServer MINOR_NUMBER in CommunicationStream.hpp

nbhuiyan · 2026-03-26T02:30:16Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+
+        logprintf(trace(), comp()->log(), "Exact compatibilty check failed - checking subtype compatibility\n");
+        TR::KnownObjectTable::Index convertedMHIndex
+            = comp()->fej9()->getConvertedMethodhandle(comp(), mhIndex, desiredMTIndex);


fej9 is being accessed in 2 different ways in the same function.

nbhuiyan · 2026-03-26T02:30:42Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+        && !knot->isNull(desiredMTIndex)) {
+        J9::ConstProvenanceGraph *cpg = comp()->constProvenanceGraph();
+        logprintf(trace(), comp()->log(), "Checking exact compatibility\n");
+        if (fej9->isMethodHandleExpectedType(comp(), mhIndex, desiredMTIndex)) {


fej9 is being accessed in 2 different ways in the same function.

nbhuiyan · 2026-03-26T02:32:23Z

runtime/compiler/net/MessageTypes.cpp

    "VM_targetMethodFromInvokeCacheArrayMemberNameObj",
    "VM_isLambdaFormGeneratedMethod",
    "VM_getMemberNameMethodInfo",
-    "VM_isMethodHandleExpectedType",


Good catch!

nbhuiyan · 2026-03-26T02:38:42Z

runtime/compiler/optimizer/MethodHandleTransformer.hpp

+     *    Eliminates calls to Invokers.checkGeneric type when:
+     *       1. Both the MethodHandle and the MethodType are known objects, and
+     *       2. The MethodType exactly matches MethodType of the asTypeCache of the MethodHandle
+     *


Maybe we should also document the case where this is true: if (fej9->isMethodHandleExpectedType(comp(), mhIndex, desiredMTIndex)), where the asTypeCache is not involved but does result in transformation.

nbhuiyan · 2026-03-26T02:42:34Z

runtime/compiler/optimizer/MethodHandleTransformer.hpp


+    /**
+     * \brief
+     *    Eliminates calls to Invokers.checkGeneric type when:


Minor typo: Invokers.checkGeneric type ---> Invokers.checkGenericType.

nbhuiyan · 2026-03-26T02:43:16Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+            return;
+        }
+
+        logprintf(trace(), comp()->log(), "Exact compatibilty check failed - checking subtype compatibility\n");


typo: compatibility

nbhuiyan · 2026-03-26T02:45:46Z

runtime/compiler/env/VMJ9.h

+     * \param desiredTypeIndex known object index of  java/lang/invoke/MethodType object
+     * \return the KOI index of the adapted method handle, which will be UNKNOWN if the MethodTypes do not match
+     */
+    virtual OMR::KnownObjectTable::Index getConvertedMethodhandle(TR::Compilation *comp,


Ideally should capitalize the H in handle for consistency. This same comment applies in other places too for this issue (such as VMJ9.cpp, VMJ9Server.hpp, etc).

nbhuiyan · 2026-03-26T02:46:05Z

runtime/compiler/env/VMJ9.cpp

+OMR::KnownObjectTable::Index TR_J9VMBase::getConvertedMethodhandle(TR::Compilation *comp,
+    TR::KnownObjectTable::Index mhIndex, TR::KnownObjectTable::Index desiredTypeIndex)
+{
+    /* Individual type compatibilty checks on each type in the MT are not needed. Since we only fold


typo: compatibility

nbhuiyan · 2026-03-26T02:54:08Z

runtime/compiler/env/VMJ9.cpp

+    uintptr_t desiredMTObject = knot->getPointer(desiredTypeIndex);
+    // there is only one MT instance per unique signature, so this check is valid
+    if (desiredMTObject == cachedMT) {
+        logprintf(comp->getOption(TR_TraceILGen), comp->log(), "Hard cache match\n");


A more appropriate logging condition is TR_TraceOptDetails here.

nbhuiyan · 2026-04-01T18:54:06Z

runtime/compiler/optimizer/MethodHandleTransformer.hpp

+     * \param node
+     *    The call node representing the call to java/lang/invoke/Invokers.checkGenericType
+     */
+    void process_java_lang_invoke_Invokers_MethodHandle_checkGenericType(TR::TreeTop *tt, TR::Node *node);


I missed this before, but the correct name for this function should be process_java_lang_invoke_Invokers_checkGenericType to be consistent with the existing pattern in use.

nbhuiyan · 2026-04-01T20:05:45Z

runtime/compiler/control/JITClientCompilationThread.cpp

+
+            TR::KnownObjectTable::Index convertedMHIndex
+                = fe->getConvertedMethodHandle(comp, mhIndex, desiredTypeIndex);
+            client->write(response, convertedMHIndex, knot->getPointerLocation(mhIndex),


Here, only convertedMHIndex is being sent back to the server, not its pointer location, which is the only thing that's needed in the client response. See how case MessageType::VM_getMethodHandleTableEntryIndex: is implemented as an example you can follow to implement this handler.

nbhuiyan · 2026-04-01T20:09:04Z

runtime/compiler/env/VMJ9Server.cpp

+    auto recv = stream->read<TR::KnownObjectTable::Index, uintptr_t *, uintptr_t *>();
+
+    knot->updateKnownObjectTableAtServer(mhIndex, std::get<1>(recv));
+    knot->updateKnownObjectTableAtServer(desiredTypeIndex, std::get<2>(recv));


There is no need to update known object info for the objects that were passed to the client. Only the result (the converted MH, whether or not the converted MH lookup was successful or not) needs updating here. See TR_J9ServerVM::getMethodHandleTableEntryIndex as an example you could follow to implement this function.

nbhuiyan · 2026-04-01T20:16:10Z

runtime/compiler/optimizer/MethodHandleTransformer.cpp

+    TR_J9VMBase *fej9 = static_cast<TR_J9VMBase *>(comp()->fe());
+    if (knot && isKnownObject(mhIndex) && !knot->isNull(mhIndex) && isKnownObject(desiredMTIndex)
+        && !knot->isNull(desiredMTIndex)) {
+        J9::ConstProvenanceGraph *cpg = comp()->constProvenanceGraph();


This line could be moved closer to where cpg is actually used.

nbhuiyan · 2026-04-01T20:20:56Z

runtime/compiler/optimizer/InterpreterEmulator.cpp

+                break;
+
+            Operand *targetMH = topn(1);
+            Operand *srcMT = topn(0);


nit: maybe a better variable names here would be mhOperand desiredMTOperand or something similar, keeping it consistent with the MethodHandleTransformer's handler. It was not immediately clear to me what target/src was supposed to mean.

nbhuiyan · 2026-04-02T19:54:25Z

runtime/compiler/optimizer/InterpreterEmulator.cpp

+            if (!comp()->useConstRefs())
+                break;
+
+            Operand *recieverMHOperand = topn(1);


nbhuiyan · 2026-04-02T19:58:42Z

runtime/compiler/env/VMJ9Server.cpp

+    stream->write(JITServer::MessageType::VM_getConvertedMethodHandle, mhIndex, desiredTypeIndex);
+    auto recv = stream->read<TR::KnownObjectTable::Index, uintptr_t *>();
+
+    TR::KnownObjectTable::Index mhIndex = std::get<0>(recv);


New declaration using same variable name as parameter here. I think you will get build errors with this. Please use a different name for this.

Adds recognized method for Invokers.checkGenericType (the callsite for MH.asType). Folds call to the asTypeCache if the MTs are exact same object. - Type checking each type in the MT in not needed. If the MT of the asTypeCache MH is the same as the MT of the target MH, we can just use the cache. If they are not the same, then we cannot fold as we have no way of obtaining the asType result at compile time. (we also should not even get here if they are not the same, since we shouldn't have a known-object for the target MT in that case). Signed-off-by: Matthew Hall <matthew.hall3@outlook.com>

0xdaryl · 2026-04-03T11:05:57Z

Jenkins test sanity all jdk21

matthewhall2 requested a review from dsouzai as a code owner March 10, 2026 19:53

matthewhall2 force-pushed the mh_fold_asType branch from b2f3e0e to a6b7aa1 Compare March 10, 2026 19:56

matthewhall2 requested review from 0xdaryl and nbhuiyan March 10, 2026 19:57

matthewhall2 force-pushed the mh_fold_asType branch 3 times, most recently from e7b9e2f to 62f4605 Compare March 10, 2026 20:45

nbhuiyan reviewed Mar 12, 2026

View reviewed changes

matthewhall2 force-pushed the mh_fold_asType branch from 62f4605 to 28671e2 Compare March 16, 2026 16:40

matthewhall2 marked this pull request as draft March 16, 2026 16:41

matthewhall2 force-pushed the mh_fold_asType branch 6 times, most recently from e63aa6b to c07d3c9 Compare March 16, 2026 20:21

matthewhall2 marked this pull request as ready for review March 16, 2026 20:43

matthewhall2 requested a review from nbhuiyan March 16, 2026 20:43

nbhuiyan suggested changes Mar 18, 2026

View reviewed changes

0xdaryl reviewed Mar 19, 2026

View reviewed changes

matthewhall2 force-pushed the mh_fold_asType branch 2 times, most recently from 9d97321 to cf8b089 Compare March 23, 2026 21:04

0xdaryl added the comp:jit label Mar 24, 2026

0xdaryl added this to Adopt OpenJDK MethodHandles Mar 24, 2026

github-project-automation bot moved this to In progress in Adopt OpenJDK MethodHandles Mar 24, 2026

matthewhall2 requested a review from nbhuiyan March 24, 2026 14:17

nbhuiyan suggested changes Mar 26, 2026

View reviewed changes

matthewhall2 force-pushed the mh_fold_asType branch from cf8b089 to fad9036 Compare March 31, 2026 15:33

matthewhall2 requested a review from nbhuiyan March 31, 2026 15:33

matthewhall2 force-pushed the mh_fold_asType branch from fad9036 to 84c1036 Compare March 31, 2026 15:56

nbhuiyan suggested changes Apr 1, 2026

View reviewed changes

matthewhall2 force-pushed the mh_fold_asType branch 2 times, most recently from eb5c169 to 9775904 Compare April 2, 2026 15:35

matthewhall2 requested a review from nbhuiyan April 2, 2026 15:41

nbhuiyan suggested changes Apr 2, 2026

View reviewed changes

matthewhall2 force-pushed the mh_fold_asType branch from 9775904 to 92f21dd Compare April 2, 2026 20:10

nbhuiyan approved these changes Apr 2, 2026

View reviewed changes

0xdaryl self-assigned this Apr 3, 2026

Conversation

matthewhall2 commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthewhall2 commented Mar 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthewhall2 commented Mar 24, 2026

Uh oh!

nbhuiyan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xdaryl commented Apr 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

matthewhall2 commented Mar 10, 2026 •

edited

Loading