RFR: 8323079: Regression of -5% to -11% with SPECjvm2008-MonteCarlo after JDK-8319451 [v2]

[Tobias Hartmann]

On Tue, 11 Jun 2024 17:35:32 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> I cannot explain the regression, comparing the current mainline to JDK-21 reveals a decrease in performance, yet it is only for some combinations of OS-GC and perfasm shows that the hot regions (>99% of execution time) do not contain differences that can explain the results.
>> 
>> Consequently, with the advice of @TobiHartmann , I propose to effectively revert JDK-8319451 for the generation of `CMove`s inside loops. For those outside, the before-JDK-8319451 probability threshold is 0.001 and the current value is 0.01. I think the current value is more reasonable as evidenced by the benchmark added in JDK-8319451.
>> 
>> Please kindly review, thank you very much.
>> Quan Anh
>
> Quan Anh Mai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Revert "8319451: PhaseIdealLoop::conditional_move is too conservative"
>   
>   This reverts commit ac968c36d7cc2e13270d28c9310178f6b654d7dc.

The OpenJDK Guide has all the details, see "Alternative 3":
https://openjdk.org/guide/#backing-out-a-change

I think creating a REDO is fine though, since we definitely want to get rid of the dependency on `BlockLayoutMinDiamondPercentage` at some point. Feel free to leave it unassigned though.

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

PR Comment: https://git.openjdk.org/jdk/pull/19650#issuecomment-2164453602