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

[Roberto Castañeda Lozano]

On Mon, 19 Aug 2024 13:43:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>>  The null check can be integrated into the oop decoding, so all Compressed Oops Modes would benefit.
>> 
>> But integrating the null check into the zero-based OOP decoding operation would require adding a conditional branch to OOP decoding (as prototyped [here](https://github.com/robcasloz/jdk/blob/ac71b1a02c8c1bd4989f762d27092fd3bf19ccd7/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L5859-L5875)), right? This would effectively mean moving the post-barrier null check above the post-barrier inter-region check, which I am not sure is beneficial.
>
> If case of heap base != null, a branch already exists which makes the other null check redundant. So, we have null check, region crossing check, another null check. Maybe this compressed oop mode is not important enough.
> 
> For the other compressed oop modes, yes, this means moving the null check above the region crossing check. On PPC64, the null check can be combined with the shift instruction, so we save one compare instruction. Technically, it would even be possible to use only one branch instruction for both checks, but I'm not sure if it's worth the complexity. I'll think about it.

OK, thanks. I just ran some benchmarks with zero-based OOP compression ([prototype here](https://github.com/robcasloz/jdk/tree/JDK-8334060-g1-late-barrier-expansion-x64-optimizations)) and could not observe any significant performance effect on three different x64 implementations. I think I will keep the `g1StoreN` implementation as-is in the x64 and aarch64 backends, for simplicity. Again, we can revisit this in follow-up work if need be.

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

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