[lworld] RFR: 8342488: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails after merging jdk-24+13

[Damon Fenacci]

On Tue, 27 May 2025 09:44:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660) has (temporarily) made `eliminate_boxing` [to false](https://github.com/dafedafe/valhalla/blob/c42af8615277a3c133bf46db0ff1f3a269421790/src/hotspot/share/opto/c2compiler.cpp#L127). This makes `Integer::valueOf` being immediately inlined instead of late-inlined (as in mainline) and this adds 1 allocation after the parsing (value class buffering?). As a consequence there is also no `Incremental Boxing Inline` anymore.
>> 
>> `ScalarReplacementWithGCBarrierTests.java` currently relies on checking the count of allocations in `AFTER_PARSING` and  `INCREMENTAL_BOXING_INLINE`. In the first case the count (1) is wrong and in the second case the phase is not present anymore.
>> 
>> On the other hand the test has been created to check that one allocation is eliminated by scalar replacement. So, the number of allocations right after parsing and the choice of `Incremental Boxing Inline` as "reference" phase to check for 2 allocation shouldn't matter (up to a certain extent).
>> 
>> To fix the issue I suggest we remove the count check after parsing and use `PHASEIDEAL_BEFORE_EA` to check for the 2 allocations instead (which is present in both cases).
>
> Thanks for working on this, Damon. The fix looks good to me.

Thanks for the review @TobiHartmann.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1474#issuecomment-2912533261