[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8180466: Clock.systemUTC has low resolution on Windows
From:       Thomas_Stüfe <thomas.stuefe () gmail ! com>
Date:       2019-02-27 17:54:30
Message-ID: CAA-vtUzxL52GxLAB=1GG=JqHx-52WR1qFExSrYGJ4NwxLpMx8g () mail ! gmail ! com
[Download RAW message or body]

On Wed, Feb 27, 2019 at 8:20 AM David Holmes <david.holmes@oracle.com>
wrote:

> Hi Thomas,
>
> I'm starting think I will have to close this as "will not fix". There is
> the performance aspect of the call itself to be potentially concerned
> about - though it would put it on a par with nanoTime() so I'm not that
> concerned. But I've also read that it can have problems during "system
> time adjustments" [1]
>
> "The high resolution of GetSystemTimePreciseAsFileTime() is derived from
> the performance counter value at the time of the call and the
> performance counter frequency. However, the performance counter
> frequency should be corrected during system time adjustments to adapt to
> the modified progress in time. Current Windows versions don't do this.
> The obtained microsecond part may be severely affected when system time
> adjustments are active. ... As of Windows 10 (Build 10240), the
> inaccuracy of GetSystemTimePreciseAsFileTime() during system time
> adjustments persists."
>
> That sounds like something that may introduce very obscure bugs. :(
>
> David
> -----
>

I agree, sorry for the lost work, but that sounds risky.

..Thomas


> This is a very interesting read!
> [1] http://www.windowstimestamp.com/description
>
> On 26/02/2019 11:12 pm, David Holmes wrote:
> > Hi Thomas,
> >
> > On 26/02/2019 8:54 pm, Thomas St=C3=BCfe wrote:
> >> Looks good.
> >
> > Thanks for taking a look.
> >
> >> I read somewhere that the ..precise.. API comes with a performance
> >> penalty, is that in some way measurable?
> >
> > Not easily as I don't have a machine I can directly run measurements on=
,
> > but I'll do some more research and see what I can do.
> >
> > Thanks,
> > David
> >
> >> Cheers, Thomas
> >>
> >> On Tue, Feb 26, 2019 at 1:32 AM David Holmes <david.holmes@oracle.com
> >> <mailto:david.holmes@oracle.com>> wrote:
> >>
> >>     bug: https://bugs.openjdk.java.net/browse/JDK-8180466
> >>     webrev: http://cr.openjdk.java.net/~dholmes/8180466/webrev/
> >>
> >>     There is a new higher-resolution system time call available in
> >> Windows
> >>     8+ and Windows Server 2012+. This enhancement uses the API if it i=
s
> >>     available at runtime.
> >>
> >>     Testing:
> >>        - manual testing using the little "benchmark" in the bug report
> on
> >>     Windows 7 (no new API) and later
> >>        - java.time tests
> >>
> >>     Thanks,
> >>     David
> >>
>
[prev in list] [next in list] [prev in thread] [next in thread]