RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v27]
Roberto Castañeda Lozano
rcastanedalo at openjdk.org
Wed Oct 2 11:42:52 UTC 2024
On Wed, 2 Oct 2024 10:10:12 GMT, Hamlin Li <mli 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 53 additional commits since the last revision:
>>
>> - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>> - riscv port refactor
>> - Remove temporary support code
>> - Merge jdk-24+17
>> - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>> - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>> - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>> - 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
>> - ... and 43 more: https://git.openjdk.org/jdk/compare/486c5b0d...14483b83
>
> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 55:
>
>> 53: }
>> 54: for (RegSetIterator<Register> reg = no_preserve.begin(); *reg != noreg; ++reg) {
>> 55: stub->dont_preserve(*reg);
>
> Could `no_preserve` and `preserve` overlap?
> If false, then seems it's not necessary to do `dont_preserve` for `no_preserve`
> If true, seems it's not safe to `dont_preserve` these regs? I'm not sure.
In the G1 case, the use of `dont_preserve` is an optimization to avoid spilling and reloading, in the slow path of the pre-barrier, registers (`res`) that are not live at that point. It is not necessary for correctness, but saves a few bytes in the generated code. If `res` was not marked as `dont_preserve`, it would be included in the pre-barrier stub's preserve set (`BarrierStubC2::preserve_set()`) because it is live out of the entire AD instruction (as computed by `BarrierSetC2::compute_liveness_at_stubs()`).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784346898
More information about the hotspot-gc-dev
mailing list