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

[Dean Long]

On Fri, 20 Jun 2025 08:58:39 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   2nd try at arm fix
>
>> > Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance.
>> 
>> For ZGC I am using a per-nmethod lock: ZLocker locker(ZNMethod::lock_for_nmethod(nm));
> 
> Ah, right. So, ZGC should be fine.
> 
>> I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this.
> 
> I have tried some SPEC benchmarks with G1 on PPC64, but couldn't observe a regression. (If there is one, it was below noise.)
>  
>> One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint.
> 
> I guess the most critical scenario is when many Java threads need to disarm a large number of nmethod entry barriers. That doesn't happen at a safepoint. Not sure if other scenarios are worth optimizing by this idea.
> 
> I guess this PR is ok as it is. Maybe other reviewers have more comments.

@TheRealMDoerr @fisk @offamitkumar 
Thanks again everyone for the reviews and contributions.  I think this is ready to integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2997672327