delta/go-git.git/src/runtime/stack.go, branch dev.go2go

runtime: reset stack poison flag accidentally set

2021-02-23T21:49:46+00:00

See if this clears failure on openbsd-amd64-68 (ahem).

Change-Id: Ifa60ef711a95e5de8ad91433ffa425f75b36c76f
Reviewed-on: https://go-review.googlesource.com/c/go/+/295629
Trust: David Chase 
Run-TryBot: David Chase 
Reviewed-by: Cherry Zhang

cmd/compile: add AMD64 parameter register defs, Arg ops, plumb to ssa.Config

2021-02-23T18:14:42+00:00

This is partial plumbing recycled from the original register abi test work;
these are the parts that translate easily.  Some other bits are deferred till
later when they are ready to be used.

For #40724.

Change-Id: Ica8c55a4526793446189725a2bc3839124feb38f
Reviewed-on: https://go-review.googlesource.com/c/go/+/260539
Trust: David Chase 
Reviewed-by: Cherry Zhang

runtime: delete gosave (dead code)

2021-02-19T00:41:17+00:00

Change-Id: Ie811526534df8622d89c5b1b81dbe19ece1c962b
Reviewed-on: https://go-review.googlesource.com/c/go/+/292110
Trust: Russ Cox 
Reviewed-by: Cherry Zhang 
Reviewed-by: Ian Lance Taylor

runtime: document, clean up internal/sys

2021-02-19T00:01:38+00:00

Document what the values in internal/sys mean.

Remove various special cases for arm64 in the code using StackAlign.

Delete Uintreg - it was for GOARCH=amd64p32,
which was specific to GOOS=nacl and has been retired.

This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.

Change-Id: I40e8fa07b4e192298b6536b98a72a751951a4383
Reviewed-on: https://go-review.googlesource.com/c/go/+/288795
Trust: Russ Cox 
Reviewed-by: Cherry Zhang 
Reviewed-by: Ian Lance Taylor

runtime: make the span allocation purpose more explicit

2020-10-26T17:27:14+00:00

This change modifies mheap's span allocation API to have each caller
declare a purpose, defined as a new enum called spanAllocType.

The purpose behind this change is two-fold:
1. Tight control over who gets to allocate heap memory is, generally
   speaking, a good thing. Every codepath that allocates heap memory
   places additional implicit restrictions on the allocator. A notable
   example of a restriction is work bufs coming from heap memory: write
   barriers are not allowed in allocation paths because then we could
   have a situation where the allocator calls into the allocator.
2. Memory statistic updating is explicit. Instead of passing an opaque
   pointer for statistic updating, which places restrictions on how that
   statistic may be updated, we use the spanAllocType to determine which
   statistic to update and how.

We also take this opportunity to group all the statistic updating code
together, which should make the accounting code a little easier to
follow.

Change-Id: Ic0b0898959ba2a776f67122f0e36c9d7d60e3085
Reviewed-on: https://go-review.googlesource.com/c/go/+/246970
Trust: Michael Knyszek 
Run-TryBot: Michael Knyszek 
TryBot-Result: Go Bot 
Reviewed-by: Michael Pratt

runtime: use sigaltstack on macOS/ARM64

2020-10-06T21:25:42+00:00

Currently we don't use sigaltstack on darwin/arm64, as is not
supported on iOS. However, it is supported on macOS. Use it.
(iOS remains unchanged.)

Change-Id: Icc154c5e2edf2dbdc8ca68741ad9157fc15a72ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/256917
Trust: Cherry Zhang 
Reviewed-by: Ian Lance Taylor

all: add GOOS=ios

2020-09-23T18:12:59+00:00

Introduce GOOS=ios for iOS systems. GOOS=ios matches "darwin"
build tag, like GOOS=android matches "linux" and GOOS=illumos
matches "solaris". Only ios/arm64 is supported (ios/amd64 is
not).

GOOS=ios and GOOS=darwin remain essentially the same at this
point. They will diverge at later time, to differentiate macOS
and iOS.

Uses of GOOS=="darwin" are changed to (GOOS=="darwin" || GOOS=="ios"),
except if it clearly means macOS (e.g. GOOS=="darwin" && GOARCH=="amd64"),
it remains GOOS=="darwin".

Updates #38485.

Change-Id: I4faacdc1008f42434599efb3c3ad90763a83b67c
Reviewed-on: https://go-review.googlesource.com/c/go/+/254740
Trust: Cherry Zhang 
Run-TryBot: Cherry Zhang 
TryBot-Result: Go Bot 
Reviewed-by: Austin Clements

runtime: disable stack shrinking in activeStackChans race window

2020-09-21T14:34:33+00:00

Currently activeStackChans is set before a goroutine blocks on a channel
operation in an unlockf passed to gopark. The trouble is that the
unlockf is called *after* the G's status is changed, and the G's status
is what is used by a concurrent mark worker (calling suspendG) to
determine that a G has successfully been suspended. In this window
between the status change and unlockf, the mark worker could try to
shrink the G's stack, and in particular observe that activeStackChans is
false. This observation will cause the mark worker to *not* synchronize
with concurrent channel operations when it should, and so updating
pointers in the sudog for the blocked goroutine (which may point to the
goroutine's stack) races with channel operations which may also
manipulate the pointer (read it, dereference it, update it, etc.).

Fix the problem by adding a new atomically-updated flag to the g struct
called parkingOnChan, which is non-zero in the race window above. Then,
in isShrinkStackSafe, check if parkingOnChan is zero. The race is
resolved like so:

* Blocking G sets parkingOnChan, then changes status in gopark.
* Mark worker successfully suspends blocking G.
* If the mark worker observes parkingOnChan is non-zero when checking
  isShrinkStackSafe, then it's not safe to shrink (we're in the race
  window).
* If the mark worker observes parkingOnChan as zero, then because
  the mark worker observed the G status change, it can be sure that
  gopark's unlockf completed, and gp.activeStackChans will be correct.

The risk of this change is low, since although it reduces the number of
places that stack shrinking is allowed, the window here is incredibly
small. Essentially, every place that it might crash now is replaced with
no shrink.

This change adds a test, but the race window is so small that it's hard
to trigger without a well-placed sleep in park_m. Also, this change
fixes stackGrowRecursive in proc_test.go to actually allocate a 128-byte
stack frame. It turns out the compiler was destructuring the "pad" field
and only allocating one uint64 on the stack.

Fixes #40641.

Change-Id: I7dfbe7d460f6972b8956116b137bc13bc24464e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/247050
Run-TryBot: Michael Knyszek 
TryBot-Result: Go Bot 
Reviewed-by: Michael Pratt 
Trust: Michael Knyszek

runtime: improve error messages after allocating a stack that is too big

2020-09-20T09:54:44+00:00

In the current implementation, we can observe crashes after calling
debug.SetMaxStack and allocating a stack larger than 4GB since
stackalloc works with 32-bit sizes. To avoid this, we define an upper
limit as the largest feasible point we can grow a stack to and provide a
better error message when we get a stack overflow.

Fixes #41228

Change-Id: I55fb0a824f47ed9fb1fcc2445a4dfd57da9ef8d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/255997
Run-TryBot: Keith Randall 
TryBot-Result: Go Bot 
Trust: Giovanni Bajo 
Reviewed-by: Keith Randall

runtime: remove darwin/arm specifc code

2020-09-11T02:58:36+00:00

That port is gone.

Change-Id: I212d435e290d1890d6cd5531be98bb692650595e
Reviewed-on: https://go-review.googlesource.com/c/go/+/254077
Run-TryBot: Cherry Zhang 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor