JDK-8320167 : aarch64: lightweight locking could possibly use fewer memory barriers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • CPU: aarch64
  • Submitted: 2023-11-15
  • Updated: 2024-11-06
  • Resolved: 2024-11-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24Resolved
Related Reports
Relates :  
JDK-8291555 - Implement alternative fast-locking scheme
Relates :  
JDK-8319801 - Recursive lightweight locking: aarch64 implementation
Description
The recent aarch64 implementation uses "/*acquire*/ true, /*release*/ true" semantics in both, MacroAssembler::lightweight_lock and MacroAssembler::lightweight_unlock.
For locking purposes, it is sufficient to use lock-acquire and release-unlock. Especially the lock operation does not need to release anything like the displaced header in legacy locking mode.
Regarding the memory model, https://github.com/openjdk/jcstress/blob/ce8a2c7747e0232fac66783c89ea4a58a3819e0f/jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/advanced/AdvancedJMM_01_SynchronizedBarriers.java#L56 and other similar tests indicate that the JMM doesn't have additional requirements.
We should check if weaker semantics are correct and improve performance.
Comments
Closing this as "Not an issue" as this is already fixed in JDK-8319801.
06-11-2024
Note that unlocking with LM_LEGACY doesn't use acquire: https://github.com/openjdk/jdk/blob/3c6ffcadfec42c544c9b0d4188e50135f608b9db/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp#L183 The release in the locking part for LM_LEGACY is needed for the displaced mark word which we don't have with LM_LIGHTWEIGHT. Thanks for taking a look!
17-11-2023
I think that would make sense as micro-optimization. AFAICS, current code borrows this strong memory semantics from LM_LEGACY: https://github.com/openjdk/jdk/blob/3c6ffcadfec42c544c9b0d4188e50135f608b9db/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp#L86-L87. But we really need to think out the implications of relaxing this code. If performance improvements are minuscule, it would be better to stay on conservative side of things.
15-11-2023