RFR: 8316180: Thread-local backoff for secondary_super_cache updates [v10]

[Aleksey Shipilev]

On Fri, 13 Oct 2023 03:43:26 GMT, nahidasu <duke at openjdk.org> wrote:

> “We see that it takes very little contention (5%) for the default behavior to perform poorly, and in the uncontended case there is no downside for using a large Backoff value. So backoff values of 1,000 or even 10,000 seem reasonable. 

Thank you! 

Looking at these results and the porters benchmarks in this PR, I am leaning to go with 1000 as the default then. My reasoning comes from two things.

First, too high backoff might affect performance in transitional states (e.g. warmup) when we want to actually update the cache to the first value. Let's ballpark the regression opportunity for a realistic-on-side-of-terrible scenario. Assume single-threaded workload, so no secondary super contention, 10K classes that need updates for secondary super, huge interface hierarchy to search through. Let's pessimistically ballpark the secondary supers scan at 100ns. This means that before all classes would populate their secondary super cache, we incur the 10^4 (classes) x 10^3 (threshold) x 10^2 (ns) = 10^9 ns = 1s CPU time of the additional performance cost. I think that is a fair cost for our deliberately bad scenario, and it is comparable with the time it takes to load, initialize and compile all those classes.

Second, the effects we see in targeted benchmarks suggest we have diminishing returns past 1000. Sometimes going from 1000 to 10000 improves the performance 1.5x..2x, but it is largely reasoning about the improvement of 20x or 40x in the targeted test that does nothing else but contending. I suspect the realistic workload would break even at much lower threshold, and the total difference for this improvement would likely to be eaten by Ahmdal's Law.

If this guess is wrong, we can reconsider the default in the future, based on real-world experience we get with this patch.

Any thoughts?

Maybe @franz1981 can test different backoff levels with this patch with Quarkus/some-other benchmarks, assuming there is still a version that is clearly affected by this issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15718#issuecomment-1766510970