Re: adaptive spinning: fall back to sleep / block?

On 09/04/2021 12:56, Andriy Gapon wrote:
> 
> 
> Until I recently looked at the actual code I was under an impression that
> the adaptive spinning is bounded and that after some time / number of spins a
> thread would go to a sleep queue or a turnstile.  But it looks that the spinning
> is actually unbounded as long as its conditions hold (some other thread owns the
> lock and that thread is running, the owner could be changing too).
> 
> In my opinion, it does not make sense to spin for "too long".
> If there was not an opportunity to take a lock quickly, then it's better to
> block waiting for it rather than keep occupying a processor.  For instance, the
> spinning can prevent another runnable thread from running.

Any opinions about this?
Thank you.

> I think that if a lock is heavily contended or its hold times are on the longer
> side (or both), then the adaptive spinning can make the system behavior
> (performance, responsiveness) worse.
> 
> Finally, I was under an impression that 'adaptive' meant some heuristic on
> whether and when to do the spinning.  _A lock owner is running_ seems to be too
> simple to qualify as 'adaptive'.
> 
> As an example, this looks like a relatively sophisticated implementation of the
> "adaptiveness":
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.cpp#l1919
> But, JIMHO, simply having a hard limit on the spin count would be better than
> what we have now.
> 
> P.S.
> This is not an area that I know well, so my confusion and ideas may be absurd.
> On the other hand, I could not find any justification for the current unbounded
> "adaptive" spinning.
> 
> 


-- 
Andriy Gapon