RFR: 8370077: C2: make Compile::_major_progress a boolean

[Vladimir Kozlov]

On Wed, 22 Oct 2025 16:33:42 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov I fear I don't understand what you're suggesting.
>> 
>> I've tried to add in my `set_major_progress(bool)` an assert to check we are not in the 3rd case, the one where the assignment-semantics and the OR-semantics mismatch (that is with `progress` parameter (old progress) unset and current `_major_progress` set). And indeed the assert does not fire in tier1-6+some other internal testing.
>
> @marc-chevalier 
> 
> Here is what I am proposing to check if functionality is preserved and answer @eme64 concern.
> 
> 1. make sure `_major_progress` accessed/updated through accessors methods.
> 2. add "new" field `_old_major_progress`
> 3. Restore old accessors methods but rename them with prefix `old_` and use them to update/access `_old_major_progress`
> 4. In new `major_progress()` add `assert((_old_major_progress > 0) == _major_progress, "should match")`. You can print values if they are not matching.

> Let's ask @vnkozlov , @TobiHartmann and @rwestrel , do any of you have a good definition for the major_progress concept?

My understanding of major_progress is to mark major change to graph which may invalidate built loop tree and dominators information and requires exit current round of loop optimization (build_and_optimize()) and run IGVN to clean graph before starting next round of loop optimizations.

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

PR Comment: https://git.openjdk.org/jdk/pull/27912#issuecomment-3433348223