On Mon, 27 Apr 2026 19:26:10 GMT, Vladimir Ivanov <[email protected]> wrote:
>> @iwanowww Looking at the history of `LiveNodeCountInliningCutoff`, it was >> initially set to 20000 by default, but then later changed to 40000 in >> https://github.com/openjdk/jdk/commit/5a00d5f6b559850dfd65488e56202586854b65cd >> for [JDK-8058148](https://bugs.openjdk.org/browse/JDK-8058148). As a >> result, I think it is perferrable to set it to 20000 by default and increase >> it upon encountering a method handle call, similar to how we handle >> `MaxNodeLimit`. I think it will reduce the chance of overinlining. What do >> you think? >> >> The benchmarks have finished, I think there is no regression and maybe one >> or two improvements. > >> I think it will reduce the chance of overinlining. What do you think? > > I agree that lower `LiveNodeCountInliningCutoff` reduces node budget for > inlining when no MH-related code is present in the compilation context. But > `LiveNodeCountInliningCutoff` effects were limited to incremental inlining > through indy/MH call sites. So, I don't think it makes initial value > favorable in any respect. Maybe just start with `NodeCountInliningCutoff` and > bump `_live_node_count_inlining_cutoff` to `LiveNodeCountInliningCutoff` when > MHs/VHs are present (if you want to preserve that logic)? > > It makes sense to add a diagnostic flag to revert inlining heuristic to > original behavior (to simplify performance analysis in the field). > > BTW, please, fix `MaxNodeLimit` usages separately. > >> The benchmarks have finished, I think there is no regression and maybe one >> or two improvements. > > Good. @iwanowww @vnkozlov Thanks very much for your reviews! @vnkozlov Thanks for the suggestion, I think with more usages of `MethodHandle` emerging, we may encounter that case. Although, I think such approach can be a little bit fragile, as one level of wrapper will invalidate that property. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30874#issuecomment-4355057925
