(S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

[Daniel D. Daugherty]

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
>