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

[Damon Fenacci]

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).

This pull request has now been integrated.

Changeset: be146831
Author:    Damon Fenacci <dfenacci at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/be146831b65fae0083fd9879674c33436245a07e
Stats:     4 lines in 2 files changed: 0 ins; 3 del; 1 mod

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

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1474