RFR: 8358751: C2: Recursive inlining check for compiled lambda forms is broken

[Vladimir Ivanov]

On Tue, 26 Aug 2025 23:21:34 GMT, Dean Long <dlong at openjdk.org> wrote:

> Can you explain why a MH invoker needs to be handled as a special case?

MH invokers don't have a receiver. They are linked to indy/MH.invoke/MH.invokeExact call sites and there's no dispatching happening when they are invoked (compared to other cases when MH.invokeBasic is used). 


> ... it seems like we should be saving the receiver info as a snapshot of arg0/local0 in the callee JVMState, ...

That's what the patch does. There's a number of places where `receiver_info` is simply copied when `JVMState` is cloned, but each compiled lambda form frame in `JVMState` should have its constant receiver (`MethodHandle` instance) recorded as `receiver_info`. (Constant receiver is a pre-requisite for inlining through `MH.invokeBasic()` to happen.)


> Don't we already save the receiver somewhere, so that late inlining works correctly?

For late inlining the situation is different: corresponding call site keeps the receiver as an argument. It's not the case with ancestor frames in deep inlined call chains. There are no guarantees that receivers from ancestor frames are still alive when a call site is being considered for inlining during parsing. (Effectively dead locals are aggressively pruned from JVMState during parsing.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26891#issuecomment-3228598940