RFR: 8343468: GenShen: Enable relocation of remembered set card tables

[Aleksey Shipilev]

On Wed, 22 Jan 2025 04:20:57 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> > I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.
> 
> @shipilev - are you suggesting to patch all `shenandoahBarrierSetAssembler_*` backend specific files to not use `load_byte_map`? It looks like we would end up in a similar situation if I go with the approach that you're suggesting - if I'm understanding it correctly.

Yes, I was thinking that if Shenandoah cannot use super-class `load_byte_map` and needs its own implementation, then it makes sense that Shenandoah barrier set should be using a special implementation directly instead of hacking the super-class implementation? 

But mostly I want to avoid unnecessary changes in files that are not related to Shenandoah :)

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2607782057