CL 424396 and CL 424397 changed timer0When/timerModifiedEarliest to
atomic.Uint64, just they're guaranted to have 64-bit alignment.
Change-Id: Idaff1059da2aac84520b9b0e34f9721a74dbba5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424794
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
I've dropped the note that sched.timeToRun is protected by sched.lock,
as it does not seem to be true.
For #53821.
Change-Id: I03f8dc6ca0bcd4ccf3ec113010a0aa39c6f7d6ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/419449
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Note that this converts pollUntil from uint64 to int64, the type used by
nanotime().
For #53821.
Change-Id: Iec9ec7e09d3350552561d0708ba6ea9e8a8ae7ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/419443
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Note that this changes the type from uint64 to int64, the type used by
nanotime(). It also adds an atomic load in pollWork(), which used to use
a non-atomic load.
For #53821.
Change-Id: I6173c90f20bfdc0e0a4bc3a7b1c798d1c429fff5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419442
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In gcController.startCycle we just compute the initial value in a
local variable before assigning to the atomic field to avoid noisy
churn.
For #53821.
Change-Id: Ibde0ac8fd49aa6bbee3bd02fe3ffb17429abd5a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/417784
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Atomic operations are used even during STW for consistency.
For #53821.
Change-Id: Ibe7afe5cf893b1288ce24fc96b7691b1f81754ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/417775
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Make sure that all the targets of 64-bit atomic operations
are actually aligned to 8 bytes. This has been a source of
bugs on 32-bit systems. (e.g. CL 399754)
The strategy is to have a simple test that just checks the
alignment of some explicitly listed fields and global variables.
Then there's a more complicated test that makes sure the list
used in the simple test is exhaustive. That test has some
limitations, but it should catch most cases, particularly new
uses of atomic operations on new or existing fields.
Unlike a runtime assert, this check is free and will catch
accesses that occur even in very unlikely code paths.
Change-Id: I25ac78df471ac33b57cb91375bd8453d6ce2814f
Reviewed-on: https://go-review.googlesource.com/c/go/+/407034
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Cuong Manh Le
Michael Pratt
Keith Randall