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

[duke]

On Mon, 26 May 2025 12:03:26 GMT, Damon Fenacci <dfenacci 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).

@dafedafe 
Your change (at version 7702086109a661e8fd165b7287bf6761605c87dd) is now ready to be sponsored by a Committer.

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

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