RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v3]
Cesar Soares Lucas
cslucas at openjdk.org
Thu Jan 23 05:45:43 UTC 2025
On Wed, 22 Jan 2025 17:00:02 GMT, Aleksey Shipilev <shade 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 :)
@shipilev - Please, take a look at the latest changes when you can.
> It would be great if you can include some performance numbers either in this PR or, preferably, in the JBS ticket.
@ysramakrishna - I'm working on that!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2608907272
More information about the shenandoah-dev
mailing list