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.
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
