RFR: 8262094: Handshake timeout scaled wrong

[David Holmes]

Hi Robbin,

On 22/02/2021 6:19 pm, Robbin Ehn wrote:
> On Mon, 22 Feb 2021 07:46:47 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Hi Robbin,
>>
>> This change seems much clearer, but to be clear the actual result is the same as the "counter" tracks nanoseconds.
>>
>> This counts as a trivial change IMO.
>>
>> Thanks,
>> David
> 
> Hi David, unfortunately I don't I agree that this is trivial:
> 
> `open/src/hotspot/os/windows/os_windows.cpp:jlong os::elapsed_frequency() {
> open/src/hotspot/os/windows/os_windows.cpp-  return performance_frequency;
> open/src/hotspot/os/windows/os_windows.cpp-}`
> 
> This value comes from QueryPerformanceFrequency, which depends on what resolution the Windows thinks is reasonable given what hardware support there are.

Yep mea culpa I completely overlooked Windows. So on Windows this change 
actually alters the timeout. So a simple fix but not trivial.

> In a virtualized env. this causes a 20.000 ms timeout to timeout after 2 s for me due to low resolution (windows only).
> (all other platforms hardcoded to NANASECONDS)
> 
> We have two more suspective uses here, which I have not investigated (but we have seem wired timeouts with both ZGC and G1, but I have seen non with parGC):
> `open/src/hotspot/share/gc/z/zMark.cpp:      _timeout(_start.value() + TimeHelper::micros_to_counter(timeout_in_micros))`
> 
> `open/src/hotspot/share/gc/g1/g1ServiceThread.cpp:  jlong delay = TimeHelper::millis_to_counter(delay_ms);`

These should only be heuristics in any case, but I don't understand why 
we would want to express a delay/timeout this way.

Cheers,
David
-----

> Thanks
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2666
>