On Tue, 5 May 2026 12:46:56 GMT, Paul Hübner <[email protected]> wrote:
> Hi all, > > This patch fixes some performance issues with AArch64's `NMethodEntryBarrier`. > > The purpose of a method entrypoint is to act as a barrier for potential GC > work. Entrypoints can be "armed", such that when the method is called, a > slow-path is triggered. This slow-path then does any necessary fixups. > > With the introduction of scalarized calling conventions in Valhalla, methods > have multiple entrypoints, depending on the calling conventions that are > used. This is due to the fact that `nmethod`s cannot be multiplexed when > scalarized. There can be up to three entrypoints for a given method. The > locations of these entrypoints is tracked via relocations. > > The problem lies within the usage of `RelocIterator`. When `static void > set_value` is called (such as when arming entrypoints), it creates a > `NativeNMethodBarrier` for each entrypoint. However, the `RelocIterator` only > finds the first relocation, meaning each embodiment of `NativeNMethodBarrier` > sees the same `_guard_addr`. Consequently, executions entering through the > other entrypoints will not see the up-to-date armed value, and be > unnecessarily slow-pathed. > > This patch introduces several improvements: > 1. Makes `NativeNMethodBarrier` use the `ldr` instructions to determine the > `_guard_addr`s, as opposed to relocations (contributed by @TobiHartmann). > This gets the correct addresses for each of the guards, and avoids having to > iterate through the `nmethod`'s relocations, which is expensive for large > methods. > 2. Consolidates all the entrypoints as first-class citizens of > `NativeNMethodBarrier`, instead of having an `NativeNMethodBarrier` per > entrypoint. This reduces object allocation, and makes the code much easier to > read for free! > 3. Stricter assertions. All entrypoints `ldr` instructions are verified (as > opposed to just the scalarized ones previously). All guard addresses are > verified to be within the `nmethod`'s instructions/stubs. > > Testing: tiers 1-4 and some adhoc testing with `--enable-preview`. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). I agree it would be better to have only a single guard value word in each nmethod. We could either emit one slot (probably in the stubs area) and have all the stubs share it, or have only one shared stub. The latter would involve using a BLR to branch to the stub instead of using the continuation label. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/2389#issuecomment-4394392428
