The Networking native code uses gettimeofday() in several places to manage timeouts. It may not the best solution because:
a) any active time-adjusting process (ntpd etc) will cause hard-to-reproduce hangs. Virtual and clusters environment is especially vulnerable to this problem.
b) despite some optimization gettimeofday() remains expensive call as it typically requires access to hardware clock
An alternative is to manage timeout in socket code by using select(),
acceptable solution is clock_gettime() / mach_absolute_time()
This issue was raise during the review ofJDK-8075484 :
http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010201.html
a) any active time-adjusting process (ntpd etc) will cause hard-to-reproduce hangs. Virtual and clusters environment is especially vulnerable to this problem.
b) despite some optimization gettimeofday() remains expensive call as it typically requires access to hardware clock
An alternative is to manage timeout in socket code by using select(),
acceptable solution is clock_gettime() / mach_absolute_time()
This issue was raise during the review of
http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010201.html
- duplicates
-
JDK-8172125 Reconsider use of JVM_CurrentTimeMillis vs. NET_GetCurrentTime in libnet
-
- Closed
-
- relates to
-
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-