RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4]

[Erik Österlund]

On Thu, 19 Jun 2025 00:20:05 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think?
>
> I think making it less slippery in one place but still leaving other races gives a false sense of security and makes the code harder to understand.  Arming the barrier is not guaranteed to be visible until there is a safepoint.  Note that AArch64 and RISCV only call increment_patching_epoch() when the guard value is set to the disarmed value, so there is no invalidation of the CPU pipeline or instruction buffer (cross modification fence) when arming.

Okay. I would have preferred to not enter the nmethod when we evaluate the guard bits under the lock that protects it and see that it's supposed to be not entrant. But I won't argue for it further if you prefer not to change that. Other than that, I think this looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2161540372