High lock contention invalidating "failover global" invalidator

[headius]

The FailoverSwitchPoint invalidator implements an invalidator that will eventually give up and always be failed. This is to reduce the overhead from global variables that are continually updated and read during the lifetime of the application.

The logic currently uses a synchronized method to do the update of the failure count and the invalidation of the existing switchpoint. As reported by @guizmaii on Gitter, some applications may see this contention in lock profiling if they are updating global variables frequently.

This invalidator is also used for invalidating the base Fixnum and Float methods, but generally I would not expect an application to be continuously redefining math operations.

I have requested that @guizmaii try to determine why global variables are being updated so much in his application, which embeds JRuby into a larger app.

I have an atomics-based improvement for FailoverSwitchPointInvalidator in progress.

Here's a result of a script updating the same global across many threads. The profiler I'm using is from https://github.com/jvm-profiling-tools/async-profiler.

Script:

loop {
  100.times.map {
    Thread.new {
      1000000.times { $foo = 1 }
    }
  }.each(&:join)
}

Top lock contention:

          ns  percent  samples  top
  ----------  -------  -------  ---
3365580097350  100.00%  2297169  org.jruby.runtime.opto.FailoverSwitchPointInvalidator

[headius]

With the fix in #5526:

Top lock contention:

          ns  percent  samples  top
  ----------  -------  -------  ---
   210857385   98.00%        4  java.util.Collections$SynchronizedSet
     4295257    2.00%      436  java.lang.ref.ReferenceQueue$Lock

[guizmaii]

@headius impressive !

Is already there a nightly build including this fix I can try with my app ?