GC and pointer masking

[Thomas Schatzl]

Hi,

On 23.05.25 15:18, Tony Printezis wrote:
> Hi all,
> 
> Pointer masking is available for some architectures (including RISC-V!). This can allow us to mark the top bits of an object reference with what type of objects it is (young / old / humongous / etc.) without needing to clear those bits explicitly before we use the reference. This can be helpful both in the GC itself but also in the barriers (e.g., efficiently filter out young objects in barriers that are not needed on young objects).
> 
> Has anyone already looked into taking advantage of pointer masking in HotSpot? I tried a couple of searches but I didn’t find anything. If there’s been a discussion on this before, can you please point me to it?
> 
I think there have been internal tests for ZGC to use pointer masking 
long time ago.
The result is that ZGC does not use HW pointer masking; I do not 
remember the main reason(s) but if I would guess:

* the advantage wasn't that big (compared to the used software barriers)
* only work on some archs, so one would need a fallback anyway
* inflexible
* masking out some bits on pointer access isn't that expensive nowadays; 
i.e. these ALU ops are much less expensive than the memory ops they cause.

For Serial/Parallel/G1 collectors I do not remember any attempts of hw 
pointer masking use for barriers. The main reasons not to try were

* only works on some archs, need fallback
* the current/near current barriers are extremely small anyway (even for 
G1, see [1] or [2]. There is some effort to selectively generate the 
filters, reducing overhead further. G1 could then also just use 
Serial/Parallel equivalent barriers without any filters).
* reduces compressed oops range as the bits need to be stored somewhere, 
which is probably the range of heap sizes most VMs run. This is a fairly 
large hurdle to overcome.
* available time to investigate; G1 barriers did not substantially 
change since its inception (only some fixes here and there). It has been 
years after initial ideas to fix them until something has been productized.

Do not know about Shenandoah barriers too much, or their attempts in 
that direction.

I think having extra bits in the references could help with now would be 
(g1) concurrent marking where they could be used to avoid some overhead 
wrt to enqueuing (not sure right now). Other potential uses are even 
more sketchy, but these features would need to carry their weight.

If you have any particular ideas, feel free to bring them up.

Hth,
   Thomas

[1] https://github.com/openjdk/jdk/pull/23739
[2] https://tschatzl.github.io/2025/02/21/new-write-barriers.html 
(Shameless plug ;))