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