Thread-Local Handshakes slowdown on single-cpu machines

[Karakó Miklós]

Hello,

Wow, thank you everyone! Can we expect that the fix be released with JDK15?

Feel free to answer my Stack Overflow question 
(https://stackoverflow.com/q/61375565/843804) too for the bounty 
(expires in 2 days).

Best,
Miklos

On 4/29/20 9:45 AM, Robbin Ehn wrote:
> Hi,
>
> On 2020-04-29 07:31, David Holmes wrote:
>> On 29/04/2020 1:26 pm, Karakó Miklós wrote:
>>> Hi Patricio,
>>>
>>> Yes, it seems like a scheduling issue for us too. One of my 
>>> colleagues spotted the following sentence in Robbin Ehn's 
>>> Handshaking HotSpot presentation 
>>> (https://youtu.be/VBCOfAJ409s?t=2222): ~"if the VM thread finds that 
>>> all threads are unsafe, it keeps spinning"
>>> Could it be that actually the VM thread gets more CPU time and 
>>> actually blocks JavaThread?
>>
>
> At the moment handshake do not use yield or sleep.
> http://hg.openjdk.java.net/jdk/jdk/file/ddb12e77e8dd/src/hotspot/share/runtime/handshake.cpp 
>
> Do while loop L184 -> L201.
>
> I have tested at least three different approaches trying to ease off the
> CPU, all off them suffered from performance regression on MP machines.
> We have internally seen this on very rare occasions on MP (we do not
> have UPs). Since this have been so rare, not trivial to fix without
> performance regression and I was under the assumption that UP were
> basically dead :), it have not been prioritized.
>
> To just fix the UP case we could add something like:
> diff -r f7919010c7c2 src/hotspot/share/runtime/handshake.cpp
> --- a/src/hotspot/share/runtime/handshake.cpp   Tue Apr 28 09:14:17 
> 2020 +0200
> +++ b/src/hotspot/share/runtime/handshake.cpp   Wed Apr 29 09:36:42 
> 2020 +0200
> @@ -200,2 +200,5 @@
>        }
> +      if (!os::is_MP()) {
> +        os::naked_yield();
> +      }
>      } while (!_op->is_completed());
>
> Since no thread can progress (assuming that one iteration is much
> shorter than a time-slice, this is extremely unlikely) there is no need
> for a second iteration until we executed something else.
>
> And should be trivial to backport to JDK 11.
>
> Thanks, Robbin