On Thu, 23 Apr 2026 11:45:38 GMT, Maurizio Cimadamore <[email protected]> wrote:
> E.g. if it's "just" an EA issue, we might only delay inlining if there's no > allocation in the bytecode of the method to be inlined. This is probably not > hard to do. The question is: is that enough? Did a couple of experiments here: 1. only delay inline methods that have no allocation bytecodes 2. make the problematic EA phase bail out if the live node count exceed a given threshold Unfortunately (1) didn't work. The issue is that when the decision is made, some of the allocations might be "hidden" inside the body of the inlined method -- e.g. in this case `dup()` is the method doing the allocation, and that's nested inside the accessors. So we can't reliably determine -- at the time where we make the decision to delay inlining of a method over the cutoff count-- as to whether the to-be-inlined method contains allocations or not. (2) seemed to achieve the desired result -- at least partially. With this tweak, C2 is no longer stuck in EA. However, the quality of the generated code ends up worse than w/o incremental inlining (~2x slower). ------------- PR Comment: https://git.openjdk.org/jdk/pull/30874#issuecomment-4305154103
