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

[Aleksey Shipilev]

On Thu, 20 Feb 2025 01:32:42 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge master
>>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>>  - Relocation of Card Tables
>
> 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);
  }
  ```

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

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