delta/go-git.git/src/runtime/sys_windows_amd64.s, branch dev.debug

runtime: make time correctly update on Wine

2017-04-25T04:30:06+00:00

Implemented low-level time system for windows on hardware (software),
which does not support memory mapped _KSYSTEM_TIME page update.

In particular this problem exists on Wine where _KSYSTEM_TIME
only contains time at the start, and is never modified.

On start we try to detect Wine and if it's so we fallback to
GetSystemTimeAsFileTime() for current time and a monotonic
timer based on QueryPerformanceCounter family of syscalls:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx

Fixes #18537

Change-Id: I269d22467ed9b0afb62056974d23e731b80c83ed
Reviewed-on: https://go-review.googlesource.com/35710
Reviewed-by: Alex Brainman 
Run-TryBot: Alex Brainman 
TryBot-Result: Gobot Gobot

time: optimize Now on darwin, windows

2017-02-09T14:45:16+00:00

Fetch both monotonic and wall time together when possible.
Avoids skew and is cheaper.

Also shave a few ns off in conversion in package time.

Compared to current implementation (after monotonic changes):

name   old time/op  new time/op  delta
Now    19.6ns ± 1%   9.7ns ± 1%  -50.63%  (p=0.000 n=41+49) darwin/amd64
Now    23.5ns ± 4%  10.6ns ± 5%  -54.61%  (p=0.000 n=30+28) windows/amd64
Now    54.5ns ± 5%  29.8ns ± 9%  -45.40%  (p=0.000 n=27+29) windows/386

More importantly, compared to Go 1.8:

name   old time/op  new time/op  delta
Now     9.5ns ± 1%   9.7ns ± 1%   +1.94%  (p=0.000 n=41+49) darwin/amd64
Now    12.9ns ± 5%  10.6ns ± 5%  -17.73%  (p=0.000 n=30+28) windows/amd64
Now    15.3ns ± 5%  29.8ns ± 9%  +94.36%  (p=0.000 n=30+29) windows/386

This brings time.Now back in line with Go 1.8 on darwin/amd64 and windows/amd64.

It's not obvious why windows/386 is still noticeably worse than Go 1.8,
but it's better than before this CL. The windows/386 speed is not too
important; the changes just keep the two architectures similar.

Change-Id: If69b94970c8a1a57910a371ee91e0d4e82e46c5d
Reviewed-on: https://go-review.googlesource.com/36428
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

time: record monotonic clock reading in time.Now, for more accurate comparisons

2017-02-03T19:04:52+00:00

See https://golang.org/design/12914-monotonic for details.

Fixes #12914.

Change-Id: I80edc2e6c012b4ace7161c84cf067d444381a009
Reviewed-on: https://go-review.googlesource.com/36255
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-by: Caleb Spare 
Reviewed-by: Ian Lance Taylor

runtime, cmd/compile: rename memclr -> memclrNoHeapPointers

2016-10-28T18:20:33+00:00

Since barrier-less memclr is only safe in very narrow circumstances,
this commit renames memclr to avoid accidentally calling memclr on
typed memory. This can cause subtle, non-deterministic bugs, so it's
worth some effort to prevent. In the near term, this will also prevent
bugs creeping in from any concurrent CLs that add calls to memclr; if
this happens, whichever patch hits master second will fail to compile.

This also adds the other new memclr variants to the compiler's
builtin.go to minimize the churn on that binary blob. We'll use these
in future commits.

Updates #17503.

Change-Id: I00eead049f5bd35ca107ea525966831f3d1ed9ca
Reviewed-on: https://go-review.googlesource.com/31369
Reviewed-by: Keith Randall 
Reviewed-by: Rick Hudson

runtime: pass windows float syscall args via XMM

2016-10-28T13:13:08+00:00

Based on the calling convention documented in:

	https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx

and long-used in golang.org/x/mobile/gl via some fixup asm:

	https://go.googlesource.com/mobile/+/master/gl/work_windows_amd64.s

Fixes #6510

Change-Id: I97e81baaa2872bcd732b1308915eb66f1ba2168f
Reviewed-on: https://go-review.googlesource.com/32173
Run-TryBot: David Crawshaw 
TryBot-Result: Gobot Gobot 
Reviewed-by: Alex Brainman 
Reviewed-by: Minux Ma

runtime: make framepointer mode safe for Windows

2016-05-26T13:53:01+00:00

A few other architectures have already defined a NOFRAME flag.
Use it to disable frame pointer code on a few very low-level functions
that must behave like Windows code.

Makes the failing os/signal test pass on a Windows gomote.

Change-Id: I982365f2c59a0aa302b4428c970846c61027cf3e
Reviewed-on: https://go-review.googlesource.com/23456
Reviewed-by: Austin Clements

runtime: change osyield to use Windows SwitchToThread

2016-04-04T10:05:05+00:00

It appears that windows osyield is just 15ms sleep on my computer
(see benchmarks below). Replace NtWaitForSingleObject in osyield
with SwitchToThread (as suggested by Dmitry).

Also add issue #14790 related benchmarks, so we can track perfomance
changes in CL 20834 and CL 20835 and beyond.

Update #14790

benchmark                             old ns/op     new ns/op     delta
BenchmarkChanToSyscallPing1ms         1953200       1953000       -0.01%
BenchmarkChanToSyscallPing15ms        31562904      31248400      -1.00%
BenchmarkSyscallToSyscallPing1ms      5247          4202          -19.92%
BenchmarkSyscallToSyscallPing15ms     5260          4374          -16.84%
BenchmarkChanToChanPing1ms            474           494           +4.22%
BenchmarkChanToChanPing15ms           468           489           +4.49%
BenchmarkOsYield1ms                   980018        75.5          -99.99%
BenchmarkOsYield15ms                  15625200      75.8          -100.00%

Change-Id: I1b4cc7caca784e2548ee3c846ca07ef152ebedce
Reviewed-on: https://go-review.googlesource.com/21294
Run-TryBot: Alex Brainman 
Reviewed-by: Dmitry Vyukov 
Run-TryBot: Dmitry Vyukov 
TryBot-Result: Gobot Gobot

runtime: increase assumed stack size in externalthreadhandler

2016-01-07T19:40:32+00:00

On Windows, externalthreadhandler currently sets the assumed stack
size for the profiler thread and the ctrlhandler threads to 8KB. The
actual stack size is determined by the SizeOfStackReserve field in the
binary set by the linker, which is currently at least 64KB (and
typically 128KB).

It turns out the profiler thread is running within a few words of the
8KB-(stack guard) bound set by externalthreadhandler. If it overflows
this bound, morestack crashes unceremoniously with an access
violation, which we then fail to handle, causing the whole process to
exit without explanation.

To avoid this problem and give us some breathing room, increase the
assumed stack size in externalthreadhandler to 32KB (there's some
unknown amount of stack already in use, so it's not safe to increase
this all the way to the reserve size).

We also document the relationships between externalthreadhandler and
SizeOfStackReserve to make this more obvious in the future.

Change-Id: I2f9f9c0892076d78e09827022ff0f2bedd9680a9
Reviewed-on: https://go-review.googlesource.com/18304
Run-TryBot: Austin Clements 
Reviewed-by: Alex Brainman 
Reviewed-by: Minux Ma

runtime: provide room for first 4 syscall parameters in windows usleep2

2015-09-15T01:12:32+00:00

Windows amd64 requires all syscall callers to provide room for first
4 parameters on stack. We do that for all our syscalls, except inside
of usleep2. In https://codereview.appspot.com/7563043#msg3 rsc says:

"We don't need the stack alignment and first 4 parameters on amd64
because it's just a system call, not an ordinary function call."

He seems to be wrong on both counts. But alignment is already fixed.
Fix parameter space now too.

Fixes #12444

Change-Id: I66a2a18d2f2c3846e3aa556cc3acc8ec6240bea0
Reviewed-on: https://go-review.googlesource.com/14282
Reviewed-by: Brad Fitzpatrick

runtime: really pass return value to Windows in externalthreadhandler

2015-04-15T05:03:42+00:00

When Windows calls externalthreadhandler it expects to receive
return value in AX. We don't set AX anywhere. Change that.
Store ctrlhandler1 and profileloop1 return values into AX before
returning from externalthreadhandler.

Fixes #10215.

Change-Id: Ied04542cc3ebe7d4a26660e970f9f78098143591
Reviewed-on: https://go-review.googlesource.com/8901
Reviewed-by: Minux Ma 
Run-TryBot: Alex Brainman 
TryBot-Result: Gobot Gobot