RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4]
Dean Long
dlong at openjdk.org
Tue Jun 17 00:13:30 UTC 2025
On Sat, 14 Jun 2025 09:23:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:
> 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<ZReentrantLock> locker(ZNMethod::lock_for_nmethod(nm));
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.
One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978525224
More information about the hotspot-runtime-dev
mailing list