RFR: 8319801: Recursive lightweight locking: aarch64 implementation
Axel Boldt-Christmas
aboldtch at openjdk.org
Wed Nov 15 08:00:51 UTC 2023
On Fri, 10 Nov 2023 13:36:51 GMT, Andrew Haley <aph at openjdk.org> wrote:
> > The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> It's probably not a good idea to use load/store exclusive, because recent AArch64 implementations scale very badly under contention. Better to use atomic update instructions.
We have found on some hardware the LSE instructions have terrible performance in the un-contended case. It is worth remembering that currently the lightweight mode is only for un-contended locking. As soon as we encounter contention we inflate to a monitor. (Caveat, if the lock is unlocked during the runtime transition we may still stay in the lightweight mode).
Until we add some sort of spinning in the runtime which attempts to stay in the lightweight mode for small critical sections with contention, I am unsure if this is a concern. Similarly when it comes to non locking bits contention. Currently this is only for hashCodes instalment. The GC bits are currently only used at safepoints (maybe an issue for Shenandoah, can't recall of the top of my head if they use the age bits outside safepoints).
When running this on hardware where LSE was not a concern we saw no detrimental effects, and on hardware where LSE had issues we saw significant gains.
It would be very good to know if there are hardware and program combinations for which this approach shows regressions. We have not seen this so far.
The inflated case still uses LSE. (CAS on the owner field).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1811967889
More information about the hotspot-dev
mailing list