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

[Martin Doerr]

On Wed, 18 Jun 2025 11:34:02 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> If I understand your concern correctly, there is no race.  The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section.  After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way.
>> And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level.
>
> 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.

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

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