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

[Erik Österlund]

On Wed, 18 Jun 2025 19:56:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code.
>> Does that make sense?
>
> Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier.

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?

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

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