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

[Emanuel Peter]

On Tue, 11 Jun 2024 16:41:01 GMT, Tobias Hartmann <thartmann 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
>
> Thanks, Quan Anh. On second thought, I think it's best to cleanly backout [JDK-8319451](https://bugs.openjdk.org/browse/JDK-8319451) for now and file a REDO to get rid of the dependency on `BlockLayoutMinDiamondPercentage`. I think this would actually require a CSR though because `BlockLayoutMinDiamondPercentage` is a product flag and we chang it's behavior.

@TobiHartmann @merykitty
Usually, you file a `[REDO]`, and make the `[BACKOUT]` a subtask. Example:
https://bugs.openjdk.org/browse/JDK-8323727

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

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