RFR: 8346280: C2: implement late barrier elision for G1 [v2]

[Roberto Castañeda Lozano]

On Fri, 31 Jan 2025 08:53:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roberto Castañeda Lozano has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge commit 'afcc2b0' into JDK-8346280-late-barrier-elision
>>  - Add new test case (store after exception)
>>  - Remove unused includes
>>  - Remove temporary UseNewCode guard
>>  - Use clearer names and document access API interface
>>  - Move ZGC-specific barrier elision code to BarrierSetC2
>>  - Set UseNewCode to true temporarily
>>  - Make elide_mach_barrier virtual
>>  - Move late barrier elision analysis from G1BarrierSetC2 to BarrierSetC2
>>  - Initial implementation
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/afcc2b03...ab47d7f8
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 570:
> 
>> 568:         }
>> 569:         break;
>> 570:       default:
> 
> ZGC also tries to elide barriers for atomic ops. Why isn't this done for G1 too?

Good question. I simply assumed that it was not safe to elide barriers for atomic operations on newly allocated objects for G1, as it is not for ZGC (see motivation [here](https://github.com/openjdk/jdk/blob/5878e45ae07404bc18518e6a2cb551a7969fddd6/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp#L764-L768)). But on second thought, that motivation seems ZGC-specific. Extending this changeset to elide G1 barriers for atomics that operate on newly allocated objects should be simple, should I do it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23235#discussion_r1937364100