runtime: time goes backwards on windows-arm64 (frequent TestGcLastTime failures)

[bcmills]

$ greplogs --dashboard -md -l -e FAIL: TestGcLastTime

2021-08-26T19:07:27-1f8d456/windows-arm64-10
2021-08-22T13:14:19-bd68459/windows-arm64-10
2021-08-19T09:11:02-3bdc179/windows-arm64-10
2021-08-16T23:03:03-df9c5d8/windows-arm64-10
2021-08-13T00:20:28-4c8ffb3/windows-arm64-10
2021-06-29T19:30:24-e294b8a/windows-arm64-10
2021-06-08T05:02:19-c20bcb6/windows-arm64-aws
2021-06-05T19:52:26-e1fa260/windows-arm64-aws

[bcmills]

These failures are new as of Go 1.17 because windows-arm64 support itself is new as of Go 1.17, so marking as release-blocker for the next release: we should not allow builder flakiness to increase from one release to the next.

(If we can determine that this test failure does not demonstrate a significant problem on the new platform, it should be skipped on that platform and the issue can be moved to the backlog.)

CC @golang/release

[aclements]

I looked through some of the logs and they all show time (as measured by time.Now().UnixNano()) moving backwards.

What's interesting is they all appear to roll over in the last 8 digits. The more significant digits are the same between the two reads. To me this suggests a shear when reading the time.

1630030642099881100 => 1630030642000853600
1629664923099568500 => 1629664923000568000
1629390290099822500 => 1629390290000990900
1629181133099089200 => 1629181133000075200
1628840582099496300 => 1628840582001301100

But I can't figure out how we would get shear at 8 decimal digits specifically. Time itself is split between seconds and nanoseconds, but nanoseconds are the bottom 9 digits. time.now in runtime/time_windows_arm64.s reads the low 32 bits and high 32 bits of the time separately with no memory barriers (this is the same on all Windows architectures), but those are in units of 100ns, so if that sheared, I would expect it to be at 100<<32 = 429496729600 ns.

@rsc wrote the windows/arm64 time.now. Also cc @zx2c4 .

[aclements]

As an experiment, I did the same comparison in hex. There's no obvious roll-over pattern in hex, so this definitely seems to be related to a decimal representation of time.

0x169f083b**935d848c** => 0x169f083b**8d767a60**
0x169dbb9cf**c439974** => 0x169dbb9cf**65cf8c0**
0x169cc1d**601dedfa4** => 0x169cc1d**5fbfad2b4**
0x169c039bd**923bd30** => 0x169c039bd**33ce7c0**
0x169acde1**23c7ed6c** => 0x169acde1**1ded966c**

[aclements]

Also cc @bufflig and @alexbrainman for thoughts.

I'm not worried about the test itself, but this seems to indicate a more fundamental issue with reading time on windows/arm64.

[aclements]

Actually, it's possible this was caused by #48476, which was fixed three days ago.

[aclements]

Nevermind, #48476 only applied to arm32.

[alexbrainman]

It could be a bug in OS. Not many people use windows-arm64 OS.

Alex

[heschi]

cc @mknyszek

[aclements]

Ping @bufflig