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

[Robbin Ehn]

Hi Erik,

Looks better than before :), don't forget copyright years before push.

/Robbin

On 10/22/18 12:59 PM, Erik Österlund wrote:
> 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