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

[David Holmes]

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
>