RFR: 8374622: StressIncrementalInlining should also randomize the processing order

[Marc Chevalier]

On Fri, 9 Jan 2026 08:39:43 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/compile.cpp line 2196:
>> 
>>> 2194: 
>>> 2195:   if (StressIncrementalInlining) {
>>> 2196:     shuffle_late_inlines();
>> 
>> It shuffles initial list, but doesn't have any effects on elements added during incremental inlining. Do we want to shuffle them as well?
>
> 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`?

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

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