RFR: 8157175: GetNanoTimeAdjustment.java fails with excessive adjustment error

[Gerard Ziemski]

Looks good.

My only feedback is that the comment you are removing:

// can't use get_nsec_fromepoch here as we need better accuracy than 1ms

seems still useful as it answers why get_nsec_fromepoch cannot be used to implement both os::javaTimeSystemUTC and os::javaTimeMillis


cheers

> On May 24, 2016, at 8:43 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8157175
> 
> webrev: http://cr.openjdk.java.net/~dholmes/8157175/webrev/
> 
> This essentially backs out the change for
> 
> https://bugs.openjdk.java.net/browse/JDK-8154710
> 
> which added the use of a faster in-memory timestamp for os::javaTimeMillis.
> 
> Unfortunately I did not realize the strong connection between os::javaTimeMillis and the java.time related os::javaTimeSystemUTC. These two functions must use the same time source so that their timestamps are consistent with each other (ie monotonic non-drecreasing).
> 
> The changes are a result of "hg backout" but keeping the clean up of rmeoving the unused getTimeMillis() and some comment changes. I also added a new comment to document the constraint.
> 
> Thanks,
> David