RFR: 8334060: Implementation of Late Barrier Expansion for G1

[Vladimir Kozlov]

On Mon, 17 Jun 2024 09:49:25 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
> 
> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
> 
> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
> 
> ## Summary of the Changes
> 
> ### Platform-Independent Changes (`src/hotspot/share`)
> 
> These consist mainly of:
> 
> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
> - temporary support for porting the JEP to the remaining platforms.
> 
> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
> 
> ### Platform-Dependent Changes (`src/hotspot/cpu`)
> 
> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
> 
> #### ADL Changes
> 
> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
> 
> #### `G1BarrierSetAssembler` Changes
> 
> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live registers, provided by the `SaveLiveRegisters` class. This c...

Just first glance.
In G1 specific .ad files predicate has check `UseG1GC && n->as_Store()->barrier_data() != 0`

But in normal .ad files you check only `n->as_Store()->barrier_data() == 0`.

>From what I see `barrier_data` is set only by G1 code now. But then why you check for `UseG1GC` in G1 specific .ad?

I also have comment about generating relocation for card table base address.

src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 297:

> 295:   // Do not use ExternalAddress to load 'byte_map_base', since 'byte_map_base' is NOT
> 296:   // a valid address and therefore is not properly handled by the relocation code.
> 297:   __ movptr(tmp2, (intptr_t)ct->card_table()->byte_map_base());  // tmp2 := card table base address

Consider using `lea` instructions and `ExternalAddress` to generate relocation:

    __ lea(tmp2, ExternalAddress((address)ct->card_table()->byte_map_base()));

The same in `generate_c1_post_barrier_runtime_stub()`

Leyden needs relocation for card table base.

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

PR Review: https://git.openjdk.org/jdk/pull/19746#pullrequestreview-2124316272
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1643661201