[master] RFR: OMWorld: Spin Changes
Coleen Phillimore
coleenp at openjdk.org
Thu May 23 19:41:18 UTC 2024
On Thu, 23 May 2024 06:54:51 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
> The fast lock spinning uses `sched_yield` which tends to be discouraged for spin locking code. Instead only use `SpinPause` with exponential backoff. Where after each failed CAS wait for exponentially more time until trying again in an attempt to reduce cache contention.
>
> This change also makes the spinning aware of safepoints, and tries to fast track the execution to next poll, which is either when successfully locked (VM backedge transition) or when going into blocked to enter the ObjectMonitor.
>
> Have not removed `OMSpins` yet, as the exact value is not determined yet. It may have to be platform specific as `SpinPause` have different characteristics on different hardware. OMSpins is the number of fast lock, with each attempt spinning for twice as much as the last, so the total number of spins are on the order of O(2^OMSpins). It will probably land somewhere on the range of 7-14 (128 -16384 spins)
src/hotspot/share/runtime/lightweightSynchronizer.cpp line 662:
> 660: }
> 661:
> 662: mark = obj()->mark();
Is this the spinning to delay creating an ObjectMonitor for this lock as long as possible? Or if deflation is observed? This seems like it'd slow down the contended case, like xalan where we want a lot of the threads to quickly park. Or is this spinning because deflation is observed (like the comment says above)?
Can you make 647-660 a function above this so it doesn't distract from the logic of the rest of enter so much?
-------------
PR Review Comment: https://git.openjdk.org/lilliput/pull/177#discussion_r1612216078
More information about the lilliput-dev
mailing list