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

[Francesco Nigro]

On Thu, 19 Oct 2023 08:00:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Editorial cleanups
>>  - RISC-V implementation
>>  - Mention ARM32 bug
>>  - Make sure benchmark runs with C1
>
> Deeper performance evaluation shows that Dacapo:pmd has regressions, that get linearly worse as we get into larger backoffs. They reach 8% at backoff=10000 with focused single-threaded tests. I am currently investigating the cause.

@shipilev 

At the time of https://github.com/netty/netty/issues/12708 I've prepared a microbenchmark which didn't requires Netty and was decent enough (warmup phase should be improved) to implement a "fix" and which contains a code pattern that will become even more relevant in the future, thanks to type switch (that I've already verified is affected by https://bugs.openjdk.org/browse/JDK-8180450 as well, at https://github.com/franz1981/java-puzzles/commit/ac38cd07b0207345295a9ed72180c60050aa0e5a) and is pretty common in middleware/low-level frameworks ie
- having an `Object` signature (eg typical of Hibernate/ORMs where user defined types are "enhanced" by implementing specific behaviours, but which types are uncknown to the framework entry points/signature)
- using chains of type checks to verify presence of specific "traits" to feed a state-machine of some type
- concrete objects which implements sets of "traits" (ie interfaces) flowing through the state machine

The microbenchmark was at https://github.com/franz1981/java-puzzles/commit/0d0579514d5be9cf8cf0fa71101e208ced5e3d28 (all classes but not `FalseSharingInstanceOfBenchmark`) and the entry point was `InstanceOfScalabilityBenchmark`.

The pattern is exactly the same of the Netty issue which affected Vertx/Quarkus, meaning that it let 2 concrete types to be checked against different type checks, but because of it, in case https://github.com/openjdk/jdk/pull/14375 kicks-in, it won't work as expected; this translate into stopping at C1 (again, like the other tests in this pr) or adding a third/forth concrete type during warmup. 

**Note**:
Some of the many DONT_INLINE could be simplified, to be sure inlining won't play any factor to simplify some type checks, but AFAIK it shouldn't be necessary here.

If the benchmark looks decent (once cleaned up) to verify the effects o the path for others user patterns, we could make use of it.
ATM I don't have free cycles to try it myself now, but talking with other team members to see how we can contribute.

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

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