RFR: 8212681: Refactor IC locking to use a fine grained CompiledICLocker

Erik Österlund erik.osterlund at oracle.com
Mon Oct 22 10:59:16 UTC 2018


Hi,

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 IC cache cleaning is 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.

The idea is to retain the coarse grained implementation of the 
synchronization when concurrent class unloading is not being used, as 
supporting fine grained locking could be more costly in memory, and 
there does not seem to be any use in doing this unless concurrent class 
unloading is being used.

Webrev:
http://cr.openjdk.java.net/~eosterlund/8212681/webrev.00/

Bug:
https://bugs.openjdk.java.net/browse/JDK-8212681

Thanks,
/Erik


More information about the hotspot-dev mailing list