RFR: 8374622: StressIncrementalInlining should also randomize the processing order

Marc Chevalier mchevalier at openjdk.org
Mon Jan 12 08:06:39 UTC 2026


On Mon, 12 Jan 2026 07:47:04 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> As it says: randomize the order the late inlines are processed, and slightly factor it with macro nodes.
>> 
>> I didn't add shuffle to the `GrowableArray` class since it seems a bit method specialized method (and it seems it'd be a controversial change to a widely use class), it would make `GrowableArray` depends on `Compile` for random number generation (or require a callback, for instance, giving a non-trivial signature and usage), I couldn't find other shuffling of such an object.
>> There is also shuffling of `UniqueNodeList` (for `StressIGVN`), but it seems hard to unify: access and length are not written quite the same, it would probably be not simpler than duplicating the implem (which is simple, so it's fine in my opinion).
>> 
>> Thanks,
>> Marc
>
> src/hotspot/share/opto/compile.cpp line 2177:
> 
>> 2175:   if (array.length() < 2) {
>> 2176:     return;
>> 2177:   }
> 
> Do we need this check?

Arguable. As you can see, it was there, and I didn't question it. But given the implementation under:

for (uint i = array.length() - 1; i >= 1; i--)

if the array is empty, something bad will happen, so we need at least this check. And then, why not also take `< 2`, at this point?

The other option is to use an increasing loop index, or a signed one. I think the decreasing loop index is natural here. A signed `i` would probably work. I think some people have opinion against that in iterations... I don't mind either way.

Overall, as it is now, we need this check. We could do without if we do other changes. I'm ok with how it's written now, especially because it keeps it similar to `PhaseIterGVN::shuffle_worklist()`, but I don't mind doing another way if someone has a strong opinion.

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

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


More information about the hotspot-compiler-dev mailing list