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

[Roberto Castañeda Lozano]

On Wed, 25 Sep 2024 04:55:35 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> I think you can do that as follow up changes as separate RFE. I am fine with removal in this JEP code.
>
>> I think you can do that as follow up changes as separate RFE. I am fine with removal in this JEP code.
> 
> Thanks, in the meantime I found the remaining case that was causing assertion failures, and managed to handle it and reintroduce the original assertion. The case is where the output of `m` is shared by multiple nodes `N = {n1, n2, ...}` and there exists at the same time a `n` in `N` such that `is_encode_and_store_pattern(n, m)`, and a different `n` in `N` such that `!is_encode_and_store_pattern(n, m)`. Here is an example of such a case:
> 
> ![ideal](https://github.com/user-attachments/assets/2122dfe0-757c-4094-b8f7-451f4380af45)
> 
> Commit f96dfe73 ensures that this case does not trigger the assertion by avoiding cloning `m` in `m -> n` if `m` is shared. This means that a few encode-and-store patterns that were matched by a single `g1EncodePAndStoreN` before are now matched with the less optimized `encodeHeapOop` + `g1StoreN`, e.g. in the above example:
> 
> ![mach-before-after](https://github.com/user-attachments/assets/a6fe5ad2-c0fb-4098-8bed-34593dafbcc5)
> 
> Luckily, this case is very infrequent so we will only miss around 1% of all optimization opportunities. In return, we can reintroduce the original assertion and be sure that the original invariants of the matcher are preserved.

@TheRealMDoerr: since there are now a few corner cases where we match a StoreN node with g1StoreN even though it stores the output of an EncodeP node, I had to remove the assertions in the x64 and ppc g1StoreN definitions, see above.

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

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