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