RFR: 8262094: Handshake timeout scaled wrong

[Robbin Ehn]

On Mon, 22 Feb 2021 11:02:04 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> 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().
>
>> 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().
> 
> Both uses a 'java type', jlong.
> For logging and logic for yielding we want a humanly understand unit that is absolute.
> Since things goes pretty fast nowadays nanseconds seems reasonable.
> Instead of to converting the elapsed_counter to nanos, it's much simpler to just get the nanos.
> But yes it would preferably with a os::time_nanos().

> `G1ServiceThread` is using `os::elapsed_counter()` but if the `frequency` used in `TimeHelper::millis_to_counter(...)` is wrong I guess we could be in trouble. @robehn, is your theory that the calculated delay in some cases could be extremely long and because of that cause the timeouts we see?

The logging during handshake timeout doesn't work on windows for some reason, when I locally fixed the logging I notice that timeout was actually 2 seconds instead of 20 seconds. But that only seems to apply to some windows versions/(virtual hardware).

During some tests I have seem results such as:
"Error: time between events 0 ns"
When looking at the code the events are serialized with a mutex, so some time must have passed but the granularity of the system is to coarse. I don't know what else this can cause.

-------------

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