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

[Roberto Castañeda Lozano]

On Tue, 24 Sep 2024 19:57:29 GMT, Vladimir Kozlov <kvn 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.

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.

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

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