RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v10]

[Roberto Castañeda Lozano]

On Fri, 30 Aug 2024 08:19:50 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> We can similarly elide the post-barrier if we can prove at compile-time that the value being written
>> is null.  That case isn't handled here though.  Instead that's checked for in 
>> `refine_barrier_by_new_val_type` and in `get_store_barrier`.  I'm not sure why it's structured
>> that way.
>
>> It might be worth saying explicitly that this is a compile-time version of the above mentioned young
> generation filter.
> 
> Done (commit [72a04c4](https://github.com/openjdk/jdk/pull/19746/commits/72a04c4e8046256ee7e811d66934d5d9e24f4c7c)), thanks.

> We can similarly elide the post-barrier if we can prove at compile-time that the value being written
is null. That case isn't handled here though. Instead that's checked for in
refine_barrier_by_new_val_type and in get_store_barrier. I'm not sure why it's structured
that way.

The reason why the compile-time null check is performed outside of `g1_can_remove_post_barrier` is for consistency with the [current mainline code](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp#L382-L388). The difference between the current and this changeset's `g1_can_remove_post_barrier` function is minimal, but this is unfortunately obscured in the patch by the temporary `G1_LATE_BARRIER_MIGRATION_SUPPORT`-guarded code.

`refine_barrier_by_new_val_type` performs a compile-time null check again at the end of C2's platform-independent optimizations (see https://bugs.openjdk.org/secure/attachment/107747/late-expansion.png) to exploit potentially stronger type information that might be revealed only after applying some optimizations. I have added a new test case that illustrates this scenario (commit [57adcfb](https://github.com/openjdk/jdk/pull/19746/commits/57adcfb04b163ba6744389d6258efe4b2ace534d)). I will study if the check in `get_store_barrier` is superseded by that in `refine_barrier_by_new_val_type`. If I can convince myself that this is the case I will consider removing the former.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1738191022