On 30/04/2016 9:28 AM, Daniel D. Daugherty wrote:
On 4/28/16 5:09 PM, David Holmes wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8154710
webrev: http://cr.openjdk.java.net/~dholmes/8154710/webrev/
src/os/solaris/vm/os_solaris.cpp
L1356: static _get_nsec_fromepoch_func_t _get_nsec_fromepoch = NULL;
nit: two spaced between the type and the var name.
Not sure why since you aren't lining up with anything.
L4444: Solaris::_pthread_setname_np = // from 11.3
Thanks for documenting the release.
L4450:
nit: why add a blank line?
Thumbs up! Nits only so feel free to fix or ignore, but don't
need another webrev.
Thanks for the review Dan - will nit fix. :)
David
Dan
This change is small in nature but somewhat broad in scope. It
"affects" the implementation of System.currentTimeMillis() in the Java
space, and os::javaTimeMillis() in the VM. But on Solaris only.
I say "affects" but the change will be unobservable other than in
terms of performance.
As of Solaris 11.3.6 a new in-memory timestamp has been made available
(not unlike what has always existed on Windows). There are actually 3
different timestamps exported but the one we are interested in is
get_nsecs_fromepoch - which is of course elapsed nanoseconds since the
epoch - which is exactly what javaTimeMillis() is, but expressed in
milliseconds. The in-memory timestamps have an update accuracy of 1ms,
so are not suitable for any other API's that want the time-of-day, but
at a greater accuracy.
Microbenchmark shows the in-memory access is approx 45% faster (19ns
on my test system) compared to the gettimeofday call (35ns).
Thanks,
David
