RFR: 8262094: Handshake timeout scaled wrong

[David Holmes]

On 22/02/2021 7:03 pm, Stefan Karlsson wrote:
> On Sun, 21 Feb 2021 18:46:46 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
> 
>> Parameter HandshakeTimeout is in milliseconds.
>> Internally we use nanoseconds.
>> HandshakeTimeout must be scaled to nanoseconds.
>>
>> Passes T1
> 
> Why are we using os::javaTimeNanos instead os::elapsed_counter()? I think we've tried to limit the usage of to places that explicitly interact with the Java side. For example, the reference processor uses os::javaTimeNanos because it interacts with java.lang.ref.SoftReference.clock. Most other places in the JVM uses os::elapsed_counter().

Runtime code (threading and sync) uses actual time units (ie 
javaTimeNanos) rather than os::elapsed_counter(). And elapsed_counter() 
uses javaTimeNanos() on all platforms but Windows. It's not really about 
interaction with Java, just about semantics. A timeout/delay in "ticks" 
would scale with CPU speed if "ticks" presented that, but 
os::elapsed_counter() doesn't - so a timeout/delay of N "counts" is 
somewhat arbitrary in duration. Conversely, of course, any timeout/delay 
expressed in ms or ns is somewhat arbitrary in terms of how much code 
may have executed in that time. But these timeouts are heuristics anyway.

Cheers,
David


> -------------
> 
> Changes requested by stefank (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/2666
>