Today, one must acquire the global CompiledIC_lock to have permission to perform certain IC updating activities. The lock is used outside of safepoints, but for example during nmethod unloading due to GC, lock free accesses are performed, which is safe due to being in a safepoint.
With concurrent class unloading introduced, the global lock is too coarse grained, and a per-nmethod mechanism is needed instead. In order to allow this, an abstract CompiledICLocker class could help ensuring the safety of IC caches, and allow both the fine grained (but density costly) approach for users of concurrent class unloading, and resort to the default global locking approach otherwise.
With concurrent class unloading introduced, the global lock is too coarse grained, and a per-nmethod mechanism is needed instead. In order to allow this, an abstract CompiledICLocker class could help ensuring the safety of IC caches, and allow both the fine grained (but density costly) approach for users of concurrent class unloading, and resort to the default global locking approach otherwise.
- relates to
-
JDK-8323065 Unneccesary CodeBlob lookup in CompiledIC::internal_set_ic_destination
- Resolved
-
JDK-8214257 IC cache not clean after cleaning assertion failure
- Closed