JDK-8363937 : G1: Do not take the global nmethod lock during Code cache cleanup
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2025-07-23
  • Updated: 2025-07-24
  • Resolved: 2025-07-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8361376 - Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64
Description
During class unloading, code cache cleanup takes a significant amount of time due to the code taking the global NMethodEntryBarrier_lock lock (when disarming the nmethod, in BarrierSetNMethod::guard_with()).

However the existing parallel nmethod cleaning in G1ParallelCleaningTask already splits the work on a per-nmethod basis, so taking this lock isn't necessary (and we are at a safepoint anyway).

Change the code to not take the lock in this situation; as an alternative, per-nmethod locks could be implemented (still it would be a waste to take these anyway) during that time.
Comments
JDK-8361376 essentially removes the lock in question.
24-07-2025