RFR: 8374622: StressIncrementalInlining should also randomize the processing order

[Marc Chevalier]

On Fri, 9 Jan 2026 20:47:24 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> 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.

With a different order (assuming budget exhaustion), we would end-up with different inlining decisions, but it would still be correct, right?

If budget runs out, randomizing the list before processing can also lead to different inlining decisions, so I guess it would be fine to indeed insert new elements anywhere after `_late_inlines_pos`.

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

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