(S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's
Daniel D. Daugherty
daniel.daugherty at oracle.com
Fri Apr 29 23:28:00 UTC 2016
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/
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.
nit: why add a blank line?
Thumbs up! Nits only so feel free to fix or ignore, but don't
need another webrev.
> 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).
More information about the core-libs-dev