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

[David Holmes]

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