RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v3]

[Cesar Soares Lucas]

On Thu, 20 Feb 2025 15:33:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/cardTable.hpp line 205:
>> 
>>> 203:   virtual CardValue* byte_map_base() const { return _byte_map_base; }
>>> 204: 
>>> 205:   virtual CardValue* byte_map() const { return _byte_map; }
>> 
>> @shipilev - can you please confirm that this is the part that you didn't like?
>
> Yes, I am not fond of extending `CardTable` with virtual members, especially if they can be used on high-performance paths. Not sure if the following idea is viable. 
> 
> ShenandoahBarrierSet knows where to get card table base: from Shenandoah thread local data. Now it looks like we need to deal with two problems:
>   1. Protect ourselves from accidentally calling `CardTable` methods that may reference "incorrect" `_byte_map_(base)`. To do that, it looks it is enough to initialize `CardTable::_byte_map_(base)` to non-sensical values (`nullptr`-s?), and let the testing crash.
>   2. Allow calls to `CardTable` utility methods with our base. For that, I think we can drill a few new (non-virtual) methods in `CardTable`, and enter from Shenandoah through them. So for example `byte_for_index(const size_t card_index)` becomes:
>   ```
>   CardValue* byte_for_index(const CardValue* base, const size_t card_index) const {
>     return base + card_index;
>   }
>   CardValue* byte_for_index(const size_t card_index) const {
>     return byte_for_index(_byte_map, card_index);
>   }
>   ```

@shipilev - can you please take a look at the latest pushes? I realized that the logic implemented already keeps the fields of the base card table class always updated, therefore I don't really need to make the methods (`_byte_map_(base)` virtual at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1978578378