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