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