On Thu, 23 Apr 2026 08:09:51 GMT, Quan Anh Mai <[email protected]> wrote:
> I can say it is intensified by how FFM is implemented, if you look at the > inline tree of AbstractMemorySegment::get above, most of the calls are below > java.lang.invoke.VarHandleSegmentAsInts::get. So, while it is often an issue > with Method/VarHandles, it is a more severe one with the FFM API. I wouldn't frame it as such. There are different users of `java.lang.invoke` API and FFM API is just one of them. FTR late inlining was introduced to fix the very same issue with inlining (`NodeCountInliningCutoff` overflow), but for code accessed through MHs. Back then Nashorn and JRuby were heavy users of MHs and they stressed the implementation in multiple ways. And, somewhat surprisingly, inlining of surrounding code wasn't a big deal for them. > I am running some benchmarks that measuring the compiler performance, as well > as familiar benchmark suites Renaissance, Dacapo, Specjbb. Good. > For the risk of overinlining, I think the risk is really small, because > normally we will hit DesiredMethodLimit first, which is based on the total > bytecode size, and it has a much smaller threshold. Personally, I'm not persuaded yet. And the difference is not that big: `DesiredMethodLimit = 8000` vs `NodeCountInliningCutoff = 18000` which translates to ~2,5 nodes per bytecode. Depending on bytecode distribution, either one can overflow first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30874#issuecomment-4307111706
