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