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

David Holmes david.holmes at oracle.com
Wed May 25 20:14:58 UTC 2016


Thanks for the Review Dan!

David

On 26/05/2016 12:02 AM, Daniel D. Daugherty wrote:
> On 5/24/16 7:43 PM, David Holmes wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8157175
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8157175/webrev/
>
> src/os/solaris/vm/os_solaris.cpp
>     No comments.
>
> The (partial) backout of JDK-8154710 looks fine.
>
> Thanks for keeping the other improvements and for adding the
> comment about os::javaTimeMillis() and os::javaTimeSystemUTC()
> needing to use the same time source.
>
> Thumbs up.
>
> Dan
>
>
>>
>> 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
>>
>


More information about the hotspot-runtime-dev mailing list