RFR: 8349652: Rewire nmethod oop load barriers

[Axel Boldt-Christmas]

On Fri, 7 Feb 2025 09:57:15 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When loading oops from nmethods we current use the Access API to inject load barriers for the GCs that requires them. As part of the ZGC load barrier we need access to the nmethod to properly perform the load barrier. The current implementation of the Access API doesn't support passing down the nmethod through all its layers of code so ZGC asks the code cache what nmethod the various oops belongs to. There's currently an open PR for JDK-8343789 (#21276), which moves the oops out of the code cache, so the current way ZGC implementation will not work after that has been integrated.
> 
> The proposal is to figure out a way to explicitly pass down the nmethod to the load barriers.
> 
> We could extend the Access API to pass down the nmethod through all its various layers. The drawback of that is that it adds a lot of boiler plate code and requires new over loads and/or names. Given that this isn't performance critical code I propose that we take the much simpler route and call straight to the BarrierSetNMethod class.
> 
> Given that MMethodAccess and IN_NMETHOD were only introduced to support nmethod oop loads for ZGC and are note used anymore I've also removed them from the code. 
> 
> Tested with reproducer for the ZGC issue in JDK-8343789, tier1-7 Linux with ZGC tasks, currently running tier1-3.

lgtm. 

Nice to get it out of the Access API. Looking at this change, seems like a lot of plumbing for two distinct loads.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23512#pullrequestreview-2620114059