RFR: 8374622: StressIncrementalInlining should also randomize the processing order

[Vladimir Ivanov]

On Fri, 9 Jan 2026 15:36:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Good point. I don't see why we wouldn't want that.
>
> Actually, I'm not sure. I see that
> https://github.com/openjdk/jdk/blob/8737a8ca73952d60129e7fc2f7e17eea3b800af7/src/hotspot/share/opto/compile.hpp#L480
> and
> https://github.com/openjdk/jdk/blob/8737a8ca73952d60129e7fc2f7e17eea3b800af7/src/hotspot/share/opto/compile.hpp#L1059-L1062
> But reading the code, I don't understand why it's important to insert just at this position, and not simply at this position or after (and then, why not at the end, to avoid shifting?). In `inline_incrementally_one`
> https://github.com/openjdk/jdk/blob/8737a8ca73952d60129e7fc2f7e17eea3b800af7/src/hotspot/share/opto/compile.cpp#L2123-L2126
> We seem to stop as soon as something happens, so we wouldn't really use the fact that the coming elements in `_late_inlines` are related. Overall, I don't see where this assumption of depth-first is used.
> 
> A little bit of testing doesn't catch fire when inserting potentially after `_late_inlines_pos`. I'll read and test more, but maybe someone already has more context? Maybe @iwanowww or @rwestrel from looking at `git blame`?

During late inlining we want to preserve relative order or candidate sites for late inlining. It matters when compiler runs out of inlining budget. If it appends candidates instead, it turns DFS call site traversal into BFS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29110#discussion_r2677580953