RFR: 8334060: Implementation of Late Barrier Expansion for G1
Vladimir Kozlov
kvn at openjdk.org
Tue Jun 18 14:48:15 UTC 2024
On Tue, 18 Jun 2024 10:17:47 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:
>> 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.
>
>> Consider using lea instructions and ExternalAddress to generate relocation:
>
> Just for my understanding, do you mean that the comment immediately above (introduced in [JDK-8028109](https://bugs.openjdk.org/browse/JDK-8028109)):
>
> // Do not use ExternalAddress to load 'byte_map_base', since 'byte_map_base' is NOT
> // a valid address and therefore is not properly handled by the relocation code.
>
> does not hold anymore in mainline?
>
>> The same in generate_c1_post_barrier_runtime_stub()
>
> Note that this JEP is not concerned with C1 barriers, in fact `generate_c1_post_barrier_runtime_stub()` is not touched by the changeset.
>
>> Leyden needs relocation for card table base.
>
> For ease of reviewing, porting, etc. I would suggest to introduce the required changes for project Leyden as a follow-up RFE, would that work?
Okay.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1644594488
More information about the hotspot-gc-dev
mailing list