RFR: 8370077: C2: make Compile::_major_progress a boolean [v4]

[Christian Hagedorn]

On Sun, 26 Oct 2025 21:20:38 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Simply change `Compile::_major_progress` from `int` to `bool` since we are only checking if it's non-zero.
>> 
>> There is one detail, we used to have
>> 
>> void          restore_major_progress(int progress) { _major_progress += progress; }
>> 
>> 
>> It is used after some verification code (maybe not only?) that may reset the major progress, using the progress saved before the said code.
>> 
>> It has a weird semantics:
>> 
>> Progress before | Progress after verification | Progress after restore | What would be the assignment semantics
>> ----------------|-----------------------------|-----------------------|-
>> 0               | 0                           | 0 | 0
>> 1               | 0                           | 1 | 1
>> 0               | 1                           | 1 | 0 (mismatch!)
>> 1               | 1                           | 2 | 1 (same truthiness)
>> 
>> It is rather a or than a restore, and a proper boolean version of that would be
>> 
>> void restore_major_progress(bool progress) { _major_progress = _major_progress || progress; }
>> 
>> but then, I'd argue the name is confusing. It also doesn't fit so well the idea that we just want to be back to the situation before the verification code. I suspect the unsaid assumption, is that the 3rd line (progress clear before, set by verification) is not possible. Anyway, I've tried with this or-semantics, or with a more natural
>> 
>> void set_major_progress(bool progress) { _major_progress = progress; }
>> 
>> that actually restore what we saved. Both pass (tier1-6 + some internal tests). Thus, I prefered the simpler semantics.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   put back the OR in restORe

Thanks for adding the summary, looks good to me, too.

src/hotspot/share/opto/compile.hpp line 332:

> 330:    *   If major progress is not set at the end of a loop opts phase, then we can stop loop opts, because we do not expect any further progress if we did more loop ops phases.
> 331:    *
> 332:    * This is not 100% accurate, the semantics of major progress has become less clear over time, but this is the general idea.

Suggestion:

   *   It also indicates that the graph was changed in a way that is promising to be able to apply more loop optimization.
   * If major progress is not set:
   *   Loop tree information is valid.
   *   If major progress is not set at the end of a loop opts phase, then we can stop loop opts, because we do not expect any further progress if we did more loop opts phases.
   *
   * This is not 100% accurate, the semantics of major progress has become less clear over time, but this is the general idea.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27912#pullrequestreview-3382206993
PR Review Comment: https://git.openjdk.org/jdk/pull/27912#discussion_r2464725986