RFR: JDK-8305711: Arm: C2 always enters slowpath for monitorexit

[Thomas Stuefe]

On Thu, 6 Apr 2023 17:00:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A small bug in the C2 implementation of monitorexit for thin locks causes us to always enter the slow path.
>> 
>> This seems to be a day zero bug of the arm port, since JEP 297: "Unified arm32/arm64 Port". It has a significant effect on locking performance, but its effect had been hidden until JDK 15 by biased locking. Biased locking removal made the bug appearant.
>> 
>> With this patch, @rkennke's artificial microbenchmark that does nothing but uncontended locking improves greatly (see https://github.com/rkennke/fastlockbench):
>> 
>> 
>> Benchmark                      (backoff)  Mode  Cnt      Score   Error  Units
>> FastLockingBenchmark.testSync          0  avgt    2    110.600          ns/op
>> FastLockingBenchmark.testSync          1  avgt    2    105.725          ns/op
>> FastLockingBenchmark.testSync          2  avgt    2    122.780          ns/op
>> FastLockingBenchmark.testSync          4  avgt    2    125.133          ns/op
>> FastLockingBenchmark.testSync          8  avgt    2    151.915          ns/op
>> FastLockingBenchmark.testSync         16  avgt    2    206.458          ns/op
>> FastLockingBenchmark.testSync         32  avgt    2    313.980          ns/op
>> FastLockingBenchmark.testSync         64  avgt    2    522.206          ns/op
>> 
>> 
>> New:
>> 
>> Benchmark                      (backoff)  Mode  Cnt      Score   Error  Units
>> FastLockingBenchmark.testSync          0  avgt    2     60.102          ns/op
>> FastLockingBenchmark.testSync          1  avgt    2     61.667          ns/op
>> FastLockingBenchmark.testSync          2  avgt    2     74.950          ns/op
>> FastLockingBenchmark.testSync          4  avgt    2     85.480          ns/op
>> FastLockingBenchmark.testSync          8  avgt    2    115.019          ns/op
>> FastLockingBenchmark.testSync         16  avgt    2    178.046          ns/op
>> FastLockingBenchmark.testSync         32  avgt    2    273.376          ns/op
>> FastLockingBenchmark.testSync         64  avgt    2    500.287          ns/op
>> 
>> 
>> Please note that Arm remains broken since JDK-8301995; I based and tested this patch on the parent of that change.
>
> Usual synopsis for ARM32 bugs is "ARM32: C2 always...", I think :)

Thanks @shipilev and @vnkozlov!

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

PR Comment: https://git.openjdk.org/jdk/pull/13376#issuecomment-1499964632