RFR: 8157175: GetNanoTimeAdjustment.java fails with excessive adjustment error
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed May 25 14:02:29 UTC 2016
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