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.
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.
- duplicates
-
JDK-8361376 Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64
-
- Open
-