RFR: 8370939: C2: SIGSEGV in SafePointNode::verify_input when processing MH call from Compile::process_late_inline_calls_no_inline() [v6]
Roland Westrelin
roland at openjdk.org
Tue Nov 25 13:13:27 UTC 2025
On Fri, 21 Nov 2025 23:41:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
> But now I see a slight change in behavior in the following part of `Compile::Compile`:
>
> ```
> if (_late_inlines.length() == 0 && !has_mh_late_inlines() && !failing() && has_stringbuilder()) {
> inline_string_calls(true);
> }
> ```
>
> After `dec_number_of_mh_late_inlines()` is gone, `inline_string_calls()` won't be called during parsing if any MH late inline calls are observed irrespective of whether they are all inlined by that point or not.
Good catch.
I think we should investigate whether removing the call to `inline_string_calls()` here and letting `Compile::inline_incrementally()` handle all string calls is good enough. That would simply things. My recollection is that there used to be a single call to `inline_string_calls()` and it was right after parsing. When late inlining was added another call was added after all inlining is over. The call after parsing was conservatively left in to make sure nothing gets broken by accident but there's a good chance, a single call after late inlining is good enough.
What I propose is: 1) I bring the number_of_mh_late_inlines logic back in this change 2) I file a bug to investigate removal of the `inline_string_calls()` (as a consequence no need for the number_of_mh_late_inlines logic).
Does that sound ok to you?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28088#issuecomment-3575577207
More information about the hotspot-compiler-dev
mailing list