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