RFR: 8308479: [s390x] Implement alternative fast-locking scheme [v8]

[Lutz Schmidt]

On Fri, 23 Jun 2023 05:44:04 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This PR implements new fast-locking scheme for s390x. Additionally few parameters have been renamed to be in sync with PPC.
>> 
>> Testing done (for release, fastdebug and slowdebug build):
>> All `test/jdk/java/util/concurrent` test with parameters:
>> * LockingMode=2 
>> * LockingMode=2 with -Xint
>> * LockingMode=2 with -XX:TieredStopAtLevel=1
>> * LockingMode=2 with -XX:-TieredCompilation
>> 
>> Result is consistently similar to Aarch(MacOS) and PPC, All of 124 tests are passing except `MapLoops.java` because in the 2nd part for this testcase, jvm starts with `HeavyMonitors` which conflict with `LockingMode=2`
>> 
>> BenchMark Result for Renaissance-jmh:
>> 
>> | Benchmark                                | Without fastLock (ms/op) | With fastLock (ms/op) | Improvement |
>> |------------------------------------------|-------------------------|----------------------|-------------|
>> | o.r.actors.JmhAkkaUct.runOperation        | 1565.080                | 1365.877             | 12.70%      |
>> | o.r.actors.JmhReactors.runOperation       | 9316.972                | 10592.982            | -13.70%     |
>> | o.r.jdk.concurrent.JmhFjKmeans.runOperation | 1257.183                | 1235.530             | 1.73%       |
>> | o.r.jdk.concurrent.JmhFutureGenetic.runOperation | 1925.158                | 2073.066             | -7.69%      |
>> | o.r.jdk.streams.JmhParMnemonics.runOperation | 2746.664                | 2836.085             | -3.24%      |
>> | o.r.jdk.streams.JmhScrabble.runOperation   | 76.774                  | 74.239               | 3.31%       |
>> | o.r.rx.JmhRxScrabble.runOperation          | 162.270                 | 167.061              | -2.96%      |
>> | o.r.scala.sat.JmhScalaDoku.runOperation    | 3333.711                | 3271.078             | 1.88%       |
>> | o.r.scala.stdlib.JmhScalaKmeans.runOperation | 182.746                 | 182.153              | 0.33%       |
>> | o.r.scala.stm.JmhPhilosophers.runOperation | 15003.329               | 13396.921            | 10.57%      |
>> | o.r.scala.stm.JmhScalaStmBench7.runOperation | 1669.090                | 1579.900             | 5.34%       |
>> | o.r.twitter.finagle.JmhFinagleChirper.runOperation | 9601.963                | 10034.404            | -4.52%      |
>> | o.r.twitter.finagle.JmhFinagleHttp.runOperation | 4403.725                | 4746.707             | -7.79%      |
>> 
>> 
>> DaCapo Benchmark Result:
>> 
>> | Benchmark                | Without fast lock (msec) | With fast lock (msec) | Improvement |
>> |--...
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestions from Martin

After struggling a lot with my environment, I finally was able to run some performance tests. There is the "db" subtest of JVM98 which caught my attention. It reproducibly shows 

- LockingMode=0: avg time: 2888ms
- LockingMode=1: avg time: 867ms
- LockingMode=2: avg time: 1020ms

We need to gain deeper insight into the why before integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/14414#issuecomment-1607837881