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

[Gerard Ziemski]

Looks good.


cheers

> On May 25, 2016, at 3:21 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 26/05/2016 3:57 AM, Gerard Ziemski wrote:
>> Looks good.
> 
> Thanks for the review Gerard!
> 
>> 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
> 
> Ok. I've update the comment as follows:
> 
> +// Must return seconds+nanos since Jan 1 1970. This must use the same
> +// time source as javaTimeMillis and can't use get_nsec_fromepoch as
> +// we need better than 1ms accuracy
> void os::javaTimeSystemUTC(jlong &seconds, jlong &nanos) {
> 
> Thanks,
> David
> 
> 
>> 
>> 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
>>