This is an attempt to mitigate JDK-8180450, while the more complex fix that would obviate the need for secondary_super_cache is being worked out. The goal for this fix is to improve performance in pathological cases, while staying simple enough for backports. 

This work implements one of the simpler ideas: Make the thread-local counter that gates the attempts to update the secondary cache. On every attempt to update the cache, we decrement the counter. Once the counter goes to zero, we accept the update to the cache and reset the counter to positive "backoff" value. This allows the single-valued cache to quickly converge to a single cached value. In case of contention that results in pathological behaviors described by JDK-8180450, this would allow dodging the contention over the secondary cache slot. _And_ it provides the longer-term safety when cache converts back to effectively single-value one: some thread would be able to finally update the cache. This also alleviates the false sharing problems for frequent secondary_super_cache updates.

The TL counter that is effectively "shared" by all class instances takes just a little bit of additional space.

It would require a bit of coding for every architecture that wants to support it, and we don't have to implement all architectures at once.