MaxGekk commented on issue #23727: [SPARK-26817][CORE] Use System.nanoTime to 
measure time intervals
URL: https://github.com/apache/spark/pull/23727#issuecomment-460514625
 
 
   @vanzin Thank you for pointing out the JIRA ticket. It is interesting but I 
don't think the concerns mentioned in the comments are still actual in this 
particular case.
   
   Looking at how 2 those calls are implemented in JDK 8 for Linux, 
[System.currentTimeMillis()](http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l1362)
   ```c
   jlong os::javaTimeMillis() {
     timeval time;
     int status = gettimeofday(&time, NULL);
     assert(status != -1, "linux error");
     return jlong(time.tv_sec) * 1000  +  jlong(time.tv_usec / 1000);
   }
   ```
   
[System.nanoTime](http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l1453)
   ```c
   jlong os::javaTimeNanos() {
     if (Linux::supports_monotonic_clock()) {
       struct timespec tp;
       int status = Linux::clock_gettime(CLOCK_MONOTONIC, &tp);
       assert(status == 0, "gettime error");
       jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + 
jlong(tp.tv_nsec);
       return result;
     } else {
       timeval time;
       int status = gettimeofday(&time, NULL);
       assert(status != -1, "linux error");
       jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
       return 1000 * usecs;
     }
   }
   ```
   As we can see, the fallback in `System.nanoTime` uses the same call 
`gettimeofday`. Here shouldn't be behavior change. It is more interesting how 
reliable the `clock_gettime(CLOCK_MONOTONIC,...)` for measurement time 
intervals is.
   
   From the JIRA ticket, there are few concerns:
   
   > ... nanotime may be fast-but-unreliable-on multiple socket systems ...
   
   In POSIX systems, `CLOCK_MONOTONIC` *represents the **monotonic** clock for 
the **system***.  
   
   > ... may downgrade to something slower than calls to getTimeMillis()
   
   I didn't find any confirmation of that. At least `clock_gettime` cannot be 
unpredictable slower.
   
   > ... even something that isn't guaranteed to be monotonic
   
   Maybe it was true in the past due to some bugs, but for now 
`CLOCK_MONOTONIC` guarantees monotonic results. It cannot jump back.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to