RFR: 8370251: C2: Inlining checks for method handle intrinsics are too strict

[Vladimir Ivanov]

On Mon, 20 Oct 2025 21:57:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/hotspot/share/opto/doCall.cpp line 245:
>> 
>>> 243:           receiver_method = callee->resolve_invoke(jvms->method()->holder(),
>>> 244:                                                    speculative_receiver_type,
>>> 245:                                                    check_access);
>> 
>> Can you explain why only here you pass `check_access` and expect it is `true` in all other places?
>
> Similar question, should we add an assert for check_access before the resolve_invoke in Compile::optimize_inlining?

> Can you explain why only here you pass check_access and expect it is true in all other places?

@vnkozlov That's the only case which was overlooked in JDK-8062280. All other cases aren't exercised for MH intrinsic methods and the asserts are there to verify that. If they start to fail, it'll signal that there may be a missing optimization opportunity.

> should we add an assert for check_access before the resolve_invoke in Compile::optimize_inlining?

@liach good question, it makes sense to separately take a closer look at this particular case. My first impression is `check_access` should be passed into ` resolve_invoke` rather than asserting `check_access == true` before `resolve_invoke`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27908#discussion_r2449730433