RFR: 8220795: Introduce TimedYield utility to improve time-to-safepoint on Windows

[David Holmes]

On 5/04/2019 7:53 pm, Robin Westberg wrote:
> Hi David,
> 
> Thanks for taking a look!
> 
>> On 5 Apr 2019, at 10:49, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Robin,
>>
>> On 5/04/2019 6:05 pm, Robin Westberg wrote:
>>> Hi all,
>>> Please review the following change that modifies the way safepointing waits for other threads to stop. As part of JDK-8203469, os::naked_short_nanosleep was used for all platforms. However, on Windows, this function has millisecond granularity which is too coarse and caused performance regressions. Instead, we can take advantage of the fact that Windows can tell us if anyone else is waiting to run on the current cpu. For other platforms the original waiting is used.
>>
>> Can't you just make the new code the implementation of os::naked_short_nanosleep on Windows and avoid adding yet another sleep/yield abstraction? If Windows nanosleep only has millisecond granularity then it's broken.
> 
> Right, I considered that approach, but it's not obvious to me what semantics would be appropriate for that. Depending on whether you want an accurate sleep or want other threads to make progress, it could conceivably be either implemented as pure spinning, or spinning combined with yielding (either cpu-local or Sleep(0)-style).
> 
> That said, perhaps os_naked_short_nanosleep should be removed, the only remaining usage is in spinYield, which turns to sleeping after giving up on yielding. For windows, it may be more appropriate to switch to Sleep(0) in that case.

I definitely don't think we need to introduce another abstraction 
(though I'm okay with replacing one with a new one).

It was probably discussed at the time but the naked_short_nanosleep on 
Windows definitely seems to have far too much overhead - even having to 
create a new waitable-timer each time. Do we know if the overhead is 
actually the resolution of the timer or whether it's all the extra work 
that method needs to do? I should try to dig up the email on that. :)

Thanks,
David

> 
> Best regards,
> Robin
> 
>>
>> Thanks,
>> David
>> -----
>>
>>> Various benchmarks (specjbb2015, specjm2008) show better numbers for Windows and no regressions for Linux.
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8220795
>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8220795/webrev.00/
>>> Testing: tier1
>>> Best regards,
>>> Robin
>