RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v2]
Martin Doerr
mdoerr at openjdk.org
Mon Aug 19 13:45:55 UTC 2024
On Mon, 19 Aug 2024 12:16:44 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:
>> Thanks for trying! I think I should try it on PPC64. The null check can be integrated into the oop decoding, so all Compressed Oops Modes would benefit. It could be that x86 is less sensitive to such optimizations.
>
>> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1721813878
More information about the hotspot-gc-dev
mailing list