Now that deferred functions are always argumentless and defer
records are no longer with arguments, defer record can be fixed
size (just the _defer struct). This allows us to simplify the
allocation of defer records, specifically, remove the defer
classes and the pools of different sized defers.
Change-Id: Icc4b16afc23b38262ca9dd1f7369ad40874cf701
Reviewed-on: https://go-review.googlesource.com/c/go/+/326062
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
newproc was not allowed to split stack because it had a special
stack layout, where the go'd function's arguments were passed on
stack but not included in the signature (therefore the stack map).
Now it no longer has argument, so it does not need to be nosplit.
Change-Id: I6f39730fb1595c4b0438c74118fef418fe1c082b
Reviewed-on: https://go-review.googlesource.com/c/go/+/325919
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
newproc/deferproc takes a siz argument for the go'd/deferred
function's argument size. Now it is always zero. Remove the
argument.
Change-Id: If1bb8d427e34015ccec0ba10dbccaae96757fa8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/325917
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Now that defer/go wrapping is used, deferred/go'd functions are
always argumentless. Remove the code handling arguments.
This CL is mostly removing the fallback code path. There are more
cleanups to be done, in later CLs.
Change-Id: I87bfd3fb2d759fbeb6487b8125c0f6992863d6e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/325915
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Hardwire regabidefers to true. Remove it from GOEXPERIMENTs.
Fallback paths are not cleaned up in this CL. That will be done
in later CLs.
Change-Id: Iec1112a1e55d5f6ef70232a5ff6e702f649071c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/325913
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Following https://golang.org/cl/291329, exitsyscall0 accesses gp.lockedm
after releasing gp to the global runq. This creates a race window where
another M may schedule the (unlocked) G, which subsequently calls
LockOSThread, setting gp.lockedm and thus causing exitsyscall0 to think
it should call stoplockedm.
Avoid this race by checking if gp is locked before releasing it to the
global runq.
Fixes#46524
Change-Id: I3acdaf09e7a2178725adbe61e985130e9ebd0680
Reviewed-on: https://go-review.googlesource.com/c/go/+/324350
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
At this point all funcPC references are ABIInternal functions.
Replace with the intrinsics.
Change-Id: I3ba7e485c83017408749b53f92877d3727a75e27
Reviewed-on: https://go-review.googlesource.com/c/go/+/321954
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
funcPC expects a func value. There are places where we pass an
unsafe.Pointer, which is technically undefined.
In proc.go it is actually representing a func value, so the
expression does the right thing. Cast to a func value so it is
clearer.
In os_freebsd.go it is a raw function pointer. Using funcPC on a
raw function pointer is incorrect. Just use it directly instead.
Change-Id: I3c5d61cea08f0abf5737834b520f9f1b583c1d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/321953
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Use FuncPCABI0 to reference ABI0 assembly symbols. Currently,
they are referenced using funcPC, which will get the ABI wrapper's
address. They don't seem to affect correctness (either the wrapper
is harmless, or, on non-AMD64 architectures, not enabled). They
should have been converted.
This CL does not yet completely eliminate funcPC. But at this
point we should be able to replace all remaining uses of funcPC
to internal/abi.FuncPCABIInternal.
Change-Id: I383a686e11d570f757f185fe46769a42c856ab77
Reviewed-on: https://go-review.googlesource.com/c/go/+/321952
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
It is valid to see SPWRITE functions at the top of a GC stack traceback,
in the case where they self-preempted during the stack growth check
and haven't actually modified SP in a traceback-unfriendly manner yet.
The current check is therefore too aggressive.
isAsyncSafePoint is taking care of not async-preempting SPWRITE functions
because it doesn't async-preempt any assembly functions at all.
But perhaps it will in the future.
To keep a check that SPWRITE assembly functions are not async-preempted,
add one in preemptPark. Then relax the check in traceback to avoid
triggering on self-preempted SPWRITE functions.
The long and short of this is that the assembly we corrected in x/crypto
issue #44269 was incredibly dodgy but not technically incompatible with
the Go runtime. After this change, the original x/crypto assembly no longer
causes GC traceback crashes during "GOGC=1 go test -count=1000".
But we'll still leave the corrected assembly.
This also means that we don't need to worry about diagnosing SPWRITE
assembly functions that may exist in the wild. They will be skipped for
async preemption and no harm no foul.
Fixes#44269, which was open pending some kind of check for
bad SPWRITE functions in the wild. (No longer needed.)
Change-Id: I6000197b62812bbd2cd92da28eab422634cf75a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/317669
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As a cleanup, golang.org/cl/307914 unintentionally caused the idle GC
work recheck to drop sched.lock between acquiring a P and committing to
keep it (once a worker G was found).
This is unsafe, as releasing a P requires extra checks once sched.lock
is taken (such as for runSafePointFn). Since checkIdleGCNoP does not
perform these extra checks, we can now race with other users.
In the case of #45975, we may hang with this sequence:
1. M1: checkIdleGCNoP takes sched.lock, gets P1, releases sched.lock.
2. M2: forEachP takes sched.lock, iterates over sched.pidle without
finding P1, releases sched.lock.
3. M1: checkIdleGCNoP puts P1 back in sched.pidle.
4. M2: forEachP waits forever for P1 to run the safePointFn.
Change back to the old behavior of releasing sched.lock only after we
are certain we will keep the P. Thus if we put it back its removal from
sched.pidle was never visible.
Fixes#45975
For #45916
For #45885
For #45884
Change-Id: I191a1800923b206ccaf96bdcdd0bfdad17b532e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/318569
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Use libc rather than performing direct system calls for the runtime on
openbsd/arm.
Updates #36435
Change-Id: If64a96a61c80b9748792f8a85a8f16ed6ebca91f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315792
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This switches openbsd/arm to thread creation via pthreads, rather than doing
direct system calls.
Update #36435
Change-Id: Ia8749e3723a9967905c33b6d93dfd9be797a486c
Reviewed-on: https://go-review.googlesource.com/c/go/+/315790
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Revive CL 310149
Change-Id: Ib4714ea5b2ade32c0f66edff841a79d8212bd79a
Reviewed-on: https://go-review.googlesource.com/c/go/+/313009
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Use libc rather than performing direct system calls for the runtime on
openbsd/386.
Updates #36435
Change-Id: I0cd65368bc824c81f5f98ea24e4f82db5468b170
Reviewed-on: https://go-review.googlesource.com/c/go/+/287653
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This switches openbsd/386 to thread creation via pthreads, rather than doing
direct system calls.
Update #36435
Change-Id: I000a815fc0edd0272c3285954f3f007229bc60a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/250577
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When ABI wrappers are used, there are cases where in Go code we
need the PC of the defined function instead of the ABI wrapper.
Currently we work around this by define such functions as
ABIInternal, even if they do not actually follow the internal ABI.
This CL introduces internal/abi.FuncPCABIxxx functions as compiler
intrinsics, which return the underlying defined function's entry
PC if the argument is a direct reference of a function of the
expected ABI, and reject it if it is of a different ABI.
As a proof of concept, change runtime.goexit back to ABI0 and use
internal/abi.FuncPCABI0 to retrieve its PC.
Updates #44065.
Change-Id: I02286f0f9d99e6a3090f9e8169dbafc6804a2da6
Reviewed-on: https://go-review.googlesource.com/c/go/+/304232
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This change adds a metric to track scheduling latencies, defined as the
cumulative amount of time a goroutine spends being runnable before
running again. The metric is an approximations and samples instead of
trying to record every goroutine scheduling latency.
This change was primarily authored by mknyszek@google.com.
Change-Id: Ie0be7e6e7be421572eb2317d3dd8dd6f3d6aa152
Reviewed-on: https://go-review.googlesource.com/c/go/+/308933
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When an M transitions from spinning to non-spinning state, it must
recheck most sources of work to avoid missing work submitted between its
initial check and decrementing sched.nmspinning (see "delicate dance"
comment).
Ever since the scheduler rewrite in Go 1.1 (golang.org/cl/7314062), we
have performed this recheck on all Ms before stopping, regardless of
whether or not they were spinning.
Unfortunately, there is a problem with this approach: non-spinning Ms
are not eligible to steal work (note the skip over the stealWork block),
but can detect work during the recheck. If there is work available, this
non-spinning M will jump to top, skip stealing, land in recheck again,
and repeat. i.e., it will spin uselessly.
The spin is bounded. This can only occur if there is another spinning M,
which will either take the work, allowing this M to stop, or take some
other work, allowing this M to upgrade to spinning. But the spinning is
ultimately just a fancy spin-wait.
golang.org/issue/43997 discusses several ways to address this. This CL
takes the simplest approach: skipping the recheck on non-spinning Ms and
allowing them to go to stop.
Results for scheduler-relevant runtime and time benchmarks can be found
at https://perf.golang.org/search?q=upload:20210420.5.
The new BenchmarkCreateGoroutinesSingle is a characteristic example
workload that hits this issue hard. A single M readies lots of work
without itself parking. Other Ms must spin to steal work, which is very
short-lived, forcing those Ms to spin again. Some of the Ms will be
non-spinning and hit the above bug.
With this fixed, that benchmark drops in CPU usage by a massive 68%, and
wall time 24%. BenchmarkNetpollBreak shows similar drops because it is
unintentionally almost the same benchmark (create short-living Gs in a
loop). Typical well-behaved programs show little change.
We also measure scheduling latency (time from goready to execute). Note
that many of these benchmarks are very noisy because they don't involve
much scheduling. Those that do, like CreateGoroutinesSingle, are
expected to increase as we are replacing unintentional spin waiting with
a real park.
Fixes#43997
Change-Id: Ie1d1e1800f393cee1792455412caaa5865d13562
Reviewed-on: https://go-review.googlesource.com/c/go/+/310850
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The runtime support for syscall.AllThreadsSyscall() functions had
some corner case deadlock issues when signal handling was in use.
This was observed in at least 3 build test failures on ppc64 and
amd64 architecture CGO_ENABLED=0 builds over the last few months.
The fixes involve more controlled handling of signals while the
AllThreads mechanism is being executed. Further details are
discussed in bug #44193.
The all-threads syscall support is new in go1.16, so earlier
releases are not affected by this bug.
Fixes#44193
Change-Id: I01ba8508a6e1bb2d872751f50da86dd07911a41d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305149
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When rechecking for work after transitioning from a spinning to
non-spinning M, checking timers before GC isn't useful. That is, if
there is GC work available, it will run immediately and the updated
pollUntil is unused.
Move this check to just before netpoll, where pollUntil is used. While
this technically improves efficiency in the (rare) case that we find
GC work in this block, the primary motivation is simply to improve
clarity by moving the update closer to use.
For #43997
Change-Id: Ibc7fb308ac4a582875c200659c9e272121a89f3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/308654
Trust: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Break the main components of the findrunnable spinning -> non-spinning
recheck out into their own functions, which simplifies both findrunnable
and the new functions, which can make use of fancy features like early
returns.
This CL should have no functional changes.
For #43997
For #44313
Change-Id: I6d3060fcecda9920a3471ff338f73d53b1d848a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/307914
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: Ida44a2e07f277bee8806538ecee4beee3474cf3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310149
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
findrunnable has grown very large and hard to follow over the years.
Parts we can split out into logical chunks should help make it more
understandable and easier to change in the future.
The work stealing loop is one such big chunk that is fairly trivial to
split out into its own function, and even has the advantage of
simplifying control flow by removing a goto around work stealing.
This CL should have no functional changes.
For #43997.
For #44313.
Change-Id: Ie69670c7bc60bd6c114e860184918717829adb22
Reviewed-on: https://go-review.googlesource.com/c/go/+/307913
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Chris Hines <chris.cs.guy@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The overview comments discuss readying goroutines, which is the most
common source of work, but timers and idle-priority GC work also require
the same synchronization w.r.t. spinning Ms.
This CL should have no functional changes.
For #43997
Updates #44313
Change-Id: I7910a7f93764dde07c3ed63666277eb832bf8299
Reviewed-on: https://go-review.googlesource.com/c/go/+/307912
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Here tryWakeP can't already be true, so there is no need to combine the
values.
This CL should have no functional changes.
For #43997.
For #44313.
Change-Id: I640c7bb88a5f70c8d22f89f0b5b146b3f60c0136
Reviewed-on: https://go-review.googlesource.com/c/go/+/307911
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
findrunnable has a couple places where delta is recomputed from a new
pollUntil value. This proves to be a pain in refactoring, as it is easy
to forget to do properly.
Move computation of delta closer to its use, where it is more logical
anyways.
This CL should have no functional changes.
For #43997.
For #44313.
Change-Id: I89980fd7f40f8a4c56c7540cae03ff99e12e1422
Reviewed-on: https://go-review.googlesource.com/c/go/+/307910
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
If GOEXPERIMENT=regabidefer is enabled, newproc currently checks that
the call frame for new goroutines is empty. But there's one place in
the runtime (debugCallWrap), where we call newproc1, and it happens to
pass a non-empty frame. The current check didn't catch that. Move the
empty call frame check from newproc to newproc1 to catch this.
Updates #40724.
Change-Id: I9998faf1e07e7b7af88e06a8177127f998c40252
Reviewed-on: https://go-review.googlesource.com/c/go/+/309034
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This adds the set of GOEXPERIMENTs to the build version if it differs
from the default set of experiments. This exposes the experiment
settings via runtime.Version() and "go version <binary>".
Change-Id: I143dbbc50f66a4cf175469199974e18848075af6
Reviewed-on: https://go-review.googlesource.com/c/go/+/307820
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, we have boolean and integral constants for GOEXPERIMENTs in
various places. Consolidate these into automatically generated
constants in the internal/goexperiment package.
Change-Id: I42a49aba2a3b4c722fedea23a613162cd8a67bee
Reviewed-on: https://go-review.googlesource.com/c/go/+/307818
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We have ways to statically access experiments now, so we don't need a
relatively clunky string-parsing dynamic way to do it.
Change-Id: I5d75480916eef4bde2c30d5fe30593180da77ff2
Reviewed-on: https://go-review.googlesource.com/c/go/+/307815
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The covers three kinds of uses:
1. Calls of closures from assembly. These are always ABIInternal calls
without wrappers. I went through every indirect call in the runtime
and I think mcall is the only case of assembly calling a Go closure in
a way that's affected by ABIInternal. systemstack also calls a
closure, but it takes no arguments.
2. Calls of Go functions that expect raw ABIInternal pointers. I also
only found one of these: callbackasm1 -> cgocallback on Windows. These
are trickier to find, though.
3. Finally, I found one case on NetBSD where new OS threads were
directly calling the Go runtime entry-point from assembly via a PC,
rather than going through a wrapper. This meant new threads may not
have special registers set up. In this case, a change on all other
OSes had already forced new thread entry to go through an ABI wrapper,
so I just caught NetBSD up with that change.
With this change, I'm able to run a "hello world" with
GOEXPERIMENT=regabi,regabiargs.
For #40724.
Change-Id: I2a6d0e530c4fd4edf13484d923891c6160d683aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/305669
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
exitsyscall0 contains two G variables: _g_ and gp. _g_ is the active G,
g0, while gp is the G to run (which just exited from a syscall).
It is passing _g_ to schedEnabled, which is incorrect; we are about to
execute gp, so that is what we should be checking the schedulability of.
While this is incorrect and should be fixed, I don't think it has ever
caused a problem in practice:
* g0 does not have g.startpc set, so schedEnabled simplifies to
just !sched.disable.user.
* This is correct provided gp is never a system goroutine.
* As far as I know, system goroutines never use entersyscall /
exitsyscall.
As far I can tell, this was a simple copy/paste error from exitsyscall,
where variable _g_ is the G to run.
While we are here, eliminate _g_ entirely, as the one other use is
identical to using gp.
Change-Id: I5df98a34569238b89ab13ff7012cd756fefb10dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/291329
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I18b9508904f19d5aa68355c937c30b5fdf35442c
Reviewed-on: https://go-review.googlesource.com/c/go/+/305249
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
On Windows, when calling into needm in cgocallback on a new thread that
is unknown to the Go runtime, we currently call through an ABI wrapper.
The ABI wrapper tries to restore the G register from TLS.
On other platforms, TLS is set up just enough that the wrapper will
simply load a nil g from TLS, but on Windows TLS isn't set up at all, so
there's nowhere for the wrapper to load from.
So, bypass the wrapper in the call to needm. needm takes no arguments
and returns no results so there are no special ABI considerations,
except that we must clear X15 which is used as a zero register in Go
code (a function normally performed by the ABI wrapper). needm is also
otherwise already special and carefully crafted to avoid doing anything
that would require a valid G or M, at least until it is able to create
one.
While we're here, this change simplifies setg so that it doesn't set up
TLS on Windows and instead provides an OS-specific osSetupTLS to do
that.
The result of this is that setg(nil) no longer clears the TLS space
pointer on Windows. There's exactly one place this is used (dropm) where
it doesn't matter anymore, and an empty TLS means that setg's wrapper
will crash on the return path. Another result is that the G slot in the
TLS will be properly cleared, however, which isn't true today.
For #40724.
Change-Id: I65c3d924a3b16abe667b06fd91d467d6d5da31d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/303070
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Previously, the runtime had to understand the full syntax of the
GOEXPERIMENT environment variable. Now, sys.GOEXPERIMENT is the
pre-processed experiment list produced by objabi, so we can simplify
the runtime parser.
Change-Id: I0d113a4347dde50a35b8b1f2b0110c88fe802921
Reviewed-on: https://go-review.googlesource.com/c/go/+/303049
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL changes GOEXPERIMENT to act like other GO[CONFIG] environment
variables. Namely, that it can be set at make.bash time to provide a
default value used by the toolchain, but then can be manually set when
running either cmd/go or the individual tools (compiler, assembler,
linker).
For example, it's now possible to test rsc.io/tmp/fieldtrack by simply
running:
GOEXPERIMENT=fieldtrack go test -gcflags=-l rsc.io/tmp/fieldtrack \
-ldflags=-k=rsc.io/tmp/fieldtrack.tracked
without needing to re-run make.bash. (-gcflags=-l is needed because
the compiler's inlining abilities have improved, so calling a function
with a for loop is no longer sufficient to suppress inlining.)
Fixes#42681.
Change-Id: I2cf8995d5d0d05f6785a2ee1d3b54b2cfb3331ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/300991
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Correctly accessing allgs is a bit hairy. Some paths need to lock
allglock, some don't. Those that don't are safest using atomicAllG, but
usage is not consistent.
Rather than doing this ad-hoc, move all access* through forEachG /
forEachGRace, the locking and atomic versions, respectively. This will
make it easier to ensure safe access.
* markroot is the only exception, as it has a far-removed guarantee of
safe access via an atomic load of allglen far before actual use.
Change-Id: Ie1c7a8243e155ae2b4bc3143577380c695680e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/279994
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I0ca1fcee6d3f08bdfcfa51f0dc774118d7355636
Reviewed-on: https://go-review.googlesource.com/c/go/+/271914
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
No change to actual runtime, but helps reduce the laundry list
of functions.
mcall, morestack, and asmcgocall are not actually top-of-frame,
so those need more attention in follow-up CLs.
mstart moved to assembly so that it can be marked TOPFRAME.
Since TOPFRAME also tells DWARF consumers not to unwind
this way, this change should also improve debuggers a
marginal amount.
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: If1e0d46ca973de5e46b62948d076f675f285b5d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/288802
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The old code was very clever about predicting whether a traceback was safe.
That cleverness has not aged well. In particular, the setsSP function is missing
a bunch of functions that write to SP and will confuse traceback.
And one such function - jmpdefer - was handled as a special case in
gentraceback instead of simply listing it in setsSP.
Throw away all the clever prediction about whether traceback will crash.
Instead, make traceback NOT crash, by checking whether the function
being walked writes to SP.
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: I3d55fe257a22745e4919ac4dc9a9378c984ba0da
Reviewed-on: https://go-review.googlesource.com/c/go/+/288801
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A g's sched.g is set in newproc1:
newg.sched.g = guintptr(unsafe.Pointer(newg))
After that, it never changes. Yet lots of assembly code does
"g.sched.g = g" unnecessarily. Remove all those lines to avoid
confusion about whether it ever changes.
Also, split gogo into two functions, one that does the nil g check
and a second that does the actual switch. This way, if the nil g check
fails, we get a stack trace showing the call stack that led to the failure.
(The SP write would otherwise cause the stack trace to abort.)
Also restore the proper nil g check in a handful of assembly functions.
(There is little point in checking for nil g *after* installing it as the real g.)
Change-Id: I22866b093f901f765de1d074e36eeec10366abfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/292109
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
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 <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cherry Mui
Matthew Dempsky
Michael Pratt
Russ Cox
Guilherme Souza
Joel Sing
Andy Pan
Andrew G. Morgan
Ian Lance Taylor
Austin Clements
徐志伟
qcrao
Michael Anthony Knyszek
John Bampton