RFR: 8319947: Recursive lightweight locking: s390x implementation [v6]

[Lutz Schmidt]

On Sun, 16 Jun 2024 09:49:42 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> s390x port for recursive locking. 
>> 
>> testing:
>> - [x] build fastdebug-vm
>> - [x] build slowdebug-vm
>> - [x] build release-vm
>> - [x] build optimized-vm
>> - [x] ./test/jdk/java/util/concurrent (fastdebug-vm)
>>   - [x] with C1
>>   - [x] with C2
>>   - [x] with interpreter 
>> - [x] ./test/jdk/java/util/concurrent (release-vm)
>>   - [x] with C1
>>   - [x] with C2
>>   - [x] with interpreter 
>> - [x] ./test/jdk/java/util/concurrent (slowdebug-vm)
>>   - [x] with C1
>>   - [x] with C2
>>   - [x] with interpreter
>> - [x] tier1 with fastdebug-vm 
>> - [x] tier1 with slowdebug-vm
>> - [x] tier1 with release-vm
>> 
>> *BenchMarks*:
>> 
>> Results from Performance LPARs : 
>> 
>> 
>> Locking Mode = 1 (without Patch)
>> 
>> Benchmark                                (innerCount)  Mode  Cnt     Score    Error  Units
>> LockUnlock.testContendedLock                      100  avgt   12     5.144 ±  0.035  ns/op
>> LockUnlock.testRecursiveLockUnlock                100  avgt   12  3824.742 ± 89.475  ns/op
>> LockUnlock.testRecursiveSynchronization           100  avgt   12    25.348 ±  0.559  ns/op
>> LockUnlock.testSerialLockUnlock                   100  avgt   12   466.629 ±  3.036  ns/op
>> LockUnlock.testSimpleLockUnlock                   100  avgt   12   468.532 ±  1.793  ns/op
>> Finished running test 'micro:vm.lang.LockUnlock'
>> 
>> Locking Mode = 1 (with patch)
>> 
>> Benchmark                                (innerCount)  Mode  Cnt     Score    Error  Units
>> LockUnlock.testContendedLock                      100  avgt   12     5.146 ±  0.027  ns/op
>> LockUnlock.testRecursiveLockUnlock                100  avgt   12  3833.175 ± 75.863  ns/op
>> LockUnlock.testRecursiveSynchronization           100  avgt   12    25.206 ±  0.519  ns/op
>> LockUnlock.testSerialLockUnlock                   100  avgt   12   473.973 ±  2.103  ns/op
>> LockUnlock.testSimpleLockUnlock                   100  avgt   12   470.749 ±  2.229  ns/op
>> Finished running test 'micro:vm.lang.LockUnlock'
>> 
>> 
>> 
>> 
>> Locking Mode = 2  (without Patch)
>> 
>> Benchmark                                (innerCount)  Mode  Cnt      Score    Error  Units
>> LockUnlock.testContendedLock                      100  avgt   12      4.688 ±  0.051  ns/op
>> LockUnlock.testRecursiveLockUnlock                100  avgt   12  12800.544 ± 92.265  ns/op
>> LockUnlock.testRecursiveSynchronization           100  avgt   12     26.486 ±  2.229  ns/op
>> LockUnlock.testSerialLockUnlock                   100  avgt   12    424.499 ±  0.416  ns/op
>> LockUnlock.te...
>
> Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into recursive_locking_v1
>  - not using load_const_optimized in compiler_fast_lock_lightweight_object
>  - minor code formatting & variable renamings
>  - revert DiagnoseSyncOnValueBasedClasses changes from c1
>  - suggestions from Axel
>  - Merge branch 'master' into recursive_locking_v1
>  - s390x recursive locking port

Looks good to me - except for that one comment incorrectness.

src/hotspot/cpu/s390/s390.ad line 9614:

> 9612:     // If unlocking was successful, cc should indicate 'EQ'.
> 9613:     // The compiler generates a branch to the runtime call to
> 9614:     // _complete_monitor_unlocking_Java for the case where cc is 'NE'.

Shouldn't the comment talk about locking here?

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18878#pullrequestreview-2138083012
PR Review Comment: https://git.openjdk.org/jdk/pull/18878#discussion_r1652399704