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

[Roberto Castañeda Lozano]

On Fri, 13 Sep 2024 22:51:59 GMT, Vladimir Kozlov <kvn 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 46 additional commits since the last revision:
>> 
>>  - Merge jdk-24+16
>>  - Ensure that detected encode-and-store patterns are matched
>>  - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>>  - Remove redundant comment
>>  - Assert that unneeded stub tmp registers are not initialized in x64 and aarch64 platforms
>>  - Set tmp registers to noreg by default in G1PreBarrierStubC2::initialize_registers, for consistency
>>  - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>>  - Restore some asserts
>>  - Default values for tmp regs of G1PostBarrierStubC2
>>  -  8334060: [arm32] Implementation of Late Barrier Expansion for G1
>>  - ... and 36 more: https://git.openjdk.org/jdk/compare/da906826...47c982ba
>
> src/hotspot/share/opto/matcher.cpp line 1821:
> 
>> 1819:   if( rule >= _END_INST_CHAIN_RULE || rule < _BEGIN_INST_CHAIN_RULE ) {
>> 1820:     assert(C->node_arena()->contains(s->_leaf) || !has_new_node(s->_leaf),
>> 1821:            "duplicating node that's already been matched");
> 
> Why it was removed?

The assertion was failing due to it being too strict in several cases where the matcher would generate valid code anyway. One of them is when `is_encode_and_store_pattern(n, m)` returns true but `m -> n` cannot be matched by a single `g1EncodePAndStoreN` instruction. Commit 9ad158b6 removes this case by ensuring that `is_encode_and_store_pattern(n, m)` holds only if `m -> n` can indeed be matched.
There are other cases (all of them harmless as far as I can see) in which this assertion can fail. I am investigating whether they can be avoided so that the assertion can be restored, and what would be the impact on the "redundant decompression removal" (`g1EncodePAndStoreN`) optimization.

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

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