Change-Id: I59c4757df83c12b4c8b85cdd523552c5e5e7bf95
Reviewed-on: https://go-review.googlesource.com/c/go/+/508977
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
We used to decrement it in netpollgoready, but that missed
the common case of a descriptor becoming ready due to I/O.
All calls to netpollgoready go through netpollunblock,
so this shouldn't miss any decrements we missed before.
Fixes#60782
Change-Id: Ideefefa1ac96ca38e09fe2dd5d595c5dd7883237
Reviewed-on: https://go-review.googlesource.com/c/go/+/503923
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: I5f06a4ef1d827eb0fe32a8d98444142108b0d573
Reviewed-on: https://go-review.googlesource.com/c/go/+/508996
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
When adding MPTCP support to address the proposal #56539, I missed the
GODEBUG setting from Russ Cox's plan:
I am inclined to say that we add MPTCP as an opt-in for a release or
two, and then make it opt-out. There should be a GODEBUG setting (...)
See: https://github.com/golang/go/issues/56539#issuecomment-1309294637
Thanks to andrius4669 for having reported this issue to me.
It makes sense to have this GODEBUG setting not to have to modify
applications to use MPTCP (if available). It can then be useful to
estimate the impact in case we want to switch from opt-in to opt-out
later.
The MPTCP E2E test has been modified to make sure we can enable MPTCP
either via the source code like it was already the case before or with
this environment variable:
GODEBUG=multipathtcp=1
The documentation has been adapted accordingly.
I don't know if it is too late for Go 1.21 but I had to put a version in
the documentation. The modification is small, the risk seems low and
this was supposed to be there from the beginning according to Russ Cox's
specifications. It can also be backported or only be present in the
future v1.22 if it is easier.
Note: I didn't re-open #56539 or open a new one. It is not clear to me
what I should do in this case.
Fixes#56539
Change-Id: I9201f4dc0b99e3643075a34c7032a95528c48fa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/507375
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
If running testprog fails, print the output.
For #60901.
Change-Id: Iee80fb09412ce13bae6ac3589779a8cdf7761765
Reviewed-on: https://go-review.googlesource.com/c/go/+/507978
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
There are some subtle details here about measuring OS stacks in cgo
programs. There's also an expectation about magnitude in the MemStats
docs that isn't in the runtime/metrics docs. Fix both.
Fixes#54396.
Change-Id: I6b60a62a4a304e6688e7ab4d511d66193fc25321
Reviewed-on: https://go-review.googlesource.com/c/go/+/502156
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This gives the user a better stack trace experience. No need to
expose them to runtime.systemstack and friends.
Fixes#61158
Change-Id: I4f423f82e54b062773067c0ae64622e37cb3948b
Reviewed-on: https://go-review.googlesource.com/c/go/+/507755
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
GCFLAGS doesn't have any defined meaning. cmd/dist enables
mayMoreStackPreempt with GOFLAGS.
For #55160.
Change-Id: I7ac71e4a1a983a56bd228ab5d24294db5cc595f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/507359
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
The latest wazero release supports non-blocking I/O and pre-opened
sockets. Unmask the relevant wasip1 tests so that there are multiple
WebAssembly runtimes exercising these code paths.
Change-Id: I8506ab35186f98fde2cd3ce84634d5fcb7b053f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/503595
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
When reusing a g struct the runtime did not reset
g.raceignore. Initialize raceignore to zero when initially
setting racectx.
A goroutine can end with a non-zero raceignore if it exits
after calling runtime.RaceDisable without a matching
runtime.RaceEnable. If that goroutine's g is later reused
the race detector is in a weird state: the underlying
g.racectx is active, yet g.raceignore is non-zero, and
raceacquire/racerelease which check g.raceignore become
no-ops. This causes the race detector to report races when
there are none.
Fixes#60934
Change-Id: Ib8e412f11badbaf69a480f03740da70891f4093f
Reviewed-on: https://go-review.googlesource.com/c/go/+/505055
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
There's more I could list here, but the mapping becomes more complicated
and more fragile. I think this is sufficient to start with.
Fixes#46846.
Change-Id: I6803486a64888b2f38e244b8e2175ad064d648ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/504115
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Change-Id: I6db8ce8d7e0a1cb3d955493fa49eb7dff372eb38
Reviewed-on: https://go-review.googlesource.com/c/go/+/504375
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In racecallatomic, we do a load before calling into TSAN, so if
the address is invalid we fault on the Go stack. We currently use
a 8-byte load instruction, regardless of the data size that the
atomic operation is performed on. So if, say, we are doing a
LoadUint32 at an address that is the last 4 bytes of a memory
mapping, we may fault unexpectedly. Do a 1-byte load instead.
(Ideally we should do a load with the right size, so we fault
correctly if we're given an unaligned address for a wide load
across a page boundary. Leave that for another CL.)
Fix AMD64, ARM64, and PPC64. The code already uses 1-byte load
on S390X.
Should fix#60825.
Change-Id: I3dee93eb08ba180c85e86a9d2e71b5b520e8dcf0
Reviewed-on: https://go-review.googlesource.com/c/go/+/503937
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Fix spelling errors discovered using https://github.com/codespell-project/codespell. Errors in data files and vendored packages are ignored.
Change-Id: I83c7818222f2eea69afbd270c15b7897678131dc
GitHub-Last-Rev: 3491615b1b
GitHub-Pull-Request: golang/go#60758
Reviewed-on: https://go-review.googlesource.com/c/go/+/502576
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
There are some symbol mismatches in the comments, this commit attempts to fix them
Change-Id: I5c9075e5218defe9233c075744d243b26ff68496
Reviewed-on: https://go-review.googlesource.com/c/go/+/492996
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This prevents a hang at a su password prompt when running this test on
OpenBSD.
Fixes#60690.
Change-Id: I62d27aa63f225f8247c324b87b5e688319061f4f
GitHub-Last-Rev: 217813a4d5
GitHub-Pull-Request: golang/go#60742
Reviewed-on: https://go-review.googlesource.com/c/go/+/502575
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Change-Id: If13f4d4bc545f78e3eb8c23cf2e63f0eb273d71f
GitHub-Last-Rev: 32ca70f52a
GitHub-Pull-Request: golang/go#60703
Reviewed-on: https://go-review.googlesource.com/c/go/+/502055
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
/gc/heap/live:bytes may exceed MemStats.HeapAlloc, even when all data is
flushed, becuase the GC may double-count objects when marking them. This
is an intentional design choice that is largely inconsequential. The
runtime is already robust to it, and the condition is rare.
Fixes#60607.
Change-Id: I4da402efc24327328d2d8780e4e49961b189f0ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/501858
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
GODEBUG=dontfreezetheworld=1 allows goroutines to continue execution
during fatal panic. This increases the chance that tracebackothers will
encounter running goroutines that it must skip, which is expected and
fine. However, it also introduces the risk that a goroutine transitions
from stopped to running in the middle of traceback, which is unsafe and
may cause traceback crashes.
Mitigate this by halting M execution if it naturally enters the
scheduler. This ensures that goroutines cannot transition from stopped
to running after freezetheworld. We simply deadlock rather than using
gcstopm to continue keeping disturbance to scheduler state to a minimum.
Change-Id: I9aa8d84abf038ae17142f34f4384e920b1490e81
Reviewed-on: https://go-review.googlesource.com/c/go/+/501255
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
On Unix platforms, the runtime previously did nothing special when a
program was run with either the SUID or SGID bits set. This can be
dangerous in certain cases, such as when dumping memory state, or
assuming the status of standard i/o file descriptors.
Taking cues from glibc, this change implements a set of protections when
a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On
Linux, whether to enable these protections is determined by whether the
AT_SECURE flag is passed in the auxiliary vector. On platforms which
have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that
is used. On the remaining platforms (currently only AIX) we check
!(getuid() == geteuid() && getgid == getegid()).
Currently when we determine a binary is "tainted" (using the glibc
terminology), we implement two specific protections:
1. we check if the file descriptors 0, 1, and 2 are open, and if they
are not, we open them, pointing at /dev/null (or fail).
2. we force GOTRACKBACK=none, and generally prevent dumping of
trackbacks and registers when a program panics/aborts.
In the future we may add additional protections.
This change requires implementing issetugid on the platforms which
support it, and implementing getuid, geteuid, getgid, and getegid on
AIX.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
Fixes#60272
Fixes CVE-2023-29403
Change-Id: I73fc93f2b7a8933c192ce3eabbf1db359db7d5fa
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501223
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test is flaky with in mayMoreStackPreempt mode. This is probably
revealing a real bug in the scheduler, but since it seems to only
affect TestCrashDumpsAllThreads, which is itself testing a debug mode,
I don't think this is high priority.
Updates #55160.
Change-Id: Iac558c098930ad8d4392b1e82b34f55eaec77c48
Reviewed-on: https://go-review.googlesource.com/c/go/+/501229
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
On Go <= 1.20 signals that caused the program to exit would eventually
call runtime.fatal. After the changes made in go.dev/cl/462437 but it
would still be nice if debuggers (eg. Delve) had a function they could
hook to intercept fatal signals.
Change-Id: Icf2b65187f95d52e60825c84f386806a75b38f6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495736
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The non-cgo test points Segv and TgkillSegv are currently in
testprogcgo. Although the test points don't explicitly use cgo,
being a cgo program, there is still some C code that runs when
the test point is invoked, such as thread creation code.
For the cgo test points, sometimes we fail to unwind the stack if
C code is involved. For the non-cgo ones, we want to always be
able to unwind the stack, so we check for stack unwinding failures.
But if a signal is landed in the small piece of C code mentioned
above, we may still fail to unwind. Move the non-cgo test points
to a pure-Go program to avoid this problem.
May fix#52963.
Updates #59029, #59443, #59492.
Change-Id: I35d99a0dd4c7cdb627e2083d2414887a24a2822d
Reviewed-on: https://go-review.googlesource.com/c/go/+/500535
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
One issue simply has a reworded message, probably from a new version of
GDB. Another is a new issue.
Fixes#60553.
Fixes#58698.
Updates #39204.
Change-Id: I8389aa981fab5421f57ee761bfb5e1dd237709ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/499975
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Currently lockextra always increments extraMInUse, even if the M won't
be used (or doesn't even exist), such as in addExtraM. addExtraM fails
to decrement extraMInUse, so it stays elevated forever.
Fix this bug and simplify the model by moving extraMInUse out of
lockextra to getExtraM, where we know the M will actually be used.
While we're here, remove the nilokay argument from getExtraM, which is
always false.
Fixes#60540.
Change-Id: I7a5d97456b3bc6ea1baeb06b5b2975e3b8dd96a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/499677
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Surprisingly, it usually survived the call to flush a write
barrier. Usually.
Fixes#60368
Change-Id: I4792a57738e5829c79baebae4d13b62abe9526b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/499679
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently the BenchmarkSetType* benchmarks are racy: they call
heapBitsSetType on an allocation that might be in a span in-use for
allocation on another P. Because heap bits are bits but are written
byte-wise non-atomically (because a P assumes it has total ownership of
a span's bits), two threads can race writing the same heap bitmap byte
creating incorrect metadata.
Fix this by forcing every value we're writing heap bits for into a large
object. Large object spans will never be written to concurrently unless
they're freed first.
Also, while we're here, refactor the benchmarks a bit. Use generics to
eliminate the reflect nastiness in gc_test.go, and pass b.ResetTimer
down into the test to get slightly more accurate results.
Fixes#60050.
Change-Id: Ib7d6249b321963367c8c8ca88385386c8ae9af1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/497215
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test was introduced as a regression test for #60276. However, it
was quite flaky on a number of different platforms because there are
myriad ways the runtime can eat into time one might expect is completely
idle.
This change re-enables the test, but makes it much more resilient.
Because the issue we're testing for is persistent, we now require 10
consecutive failures to count. Any single success counts as a test
success. This change also makes the test's idle time bound more lenient,
allowing for a little bit of time to be eaten up. The regression we're
testing for results in nearly zero idle time being accounted for.
If this is still not good enough to eliminate flakes, this test should
just be deleted.
For #60276.
Fixes#60376.
Change-Id: Icd81f0c9970821b7f386f6d27c8a566fee4d0ff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/498274
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
CL 494915 broke non-blocking I/O on wasip1 for files
opened with os.NewFile. This is fixed by providing an
implementation of fcntl(F_GETFL) for wasip1.
Change-Id: I78979076b95495fd4b94814552e5f5b043270cd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/498195
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
This comment claims mark termination re-scans stacks and uses the
write barrier to determine how much of the stack needs to be
rescanned. This hasn't been true since we introduced the hybrid write
barrier and deleted stack rescanning with CL 31766 in Go 1.8.
Updates #17503 I suppose.
Change-Id: I5e90f25020c9fa6f146ec6ed0642ba2b4884c2a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/498435
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
A var is problematic because the zero value is already false,
so if it goes away, it will appear to be false.
I'm also not sure about go:linkname on vars,
so switch to func for both reasons.
Also add a test.
Change-Id: I2318a5390d98577aec025152e65543491489defb
Reviewed-on: https://go-review.googlesource.com/c/go/+/498261
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Disable the android and ios builds since cross-compiling fails there.
Also make runtime/internal/wasitest not build on systems that don't
have syscall.Mkfifo for it to use (including, ironically, wasm itself).
Change-Id: I28eb1f216f9952f81a107056e97ee38e350f9287
Reviewed-on: https://go-review.googlesource.com/c/go/+/498255
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
heapObjectsCanMove is always false in the current garbage collector.
It exists for go4.org/unsafe/assume-no-moving-gc, which is an
unfortunate idea that had an even more unfortunate implementation.
Every time a new Go release happened, the package stopped building,
and the authors had to add a new file with a new //go:build line, and
then the entire ecosystem of packages with that as a dependency had to
explicitly update to the new version. Many packages depend on
assume-no-moving-gc transitively, through paths like
inet.af/netaddr -> go4.org/intern -> assume-no-moving-gc.
This was causing a significant amount of friction around each new
release, so we added this bool for the package to //go:linkname
instead. The bool is still unfortunate, but it's not as bad as
breaking the ecosystem on every new release.
If the Go garbage collector ever does move heap objects, we can set
this to true to break all the programs using assume-no-moving-gc.
Change-Id: I06c32bf6ccc4601c8eef741d7382b678aada3508
Reviewed-on: https://go-review.googlesource.com/c/go/+/498121
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Implements net.FileListener and net.FileConn for wasip1.
net.FileListener can be used with a pre-opened socket. If the WASM
module knows the file descriptor, a listener can be constructed with:
l, err := net.FileListener(os.NewFile(fd, ""))
If the WASM module does not know the file descriptor, but knows that at
least one of the preopens is a socket, it can find the file descriptor
and construct a listener like so:
func findListener() (net.Listener, error) {
// We start looking for pre-opened sockets at fd=3 because 0, 1,
// and 2 are reserved for stdio. Pre-opened directories also
// start at fd=3, so we skip fds that aren't sockets. Once we
// reach EBADF we know there are no more pre-opens.
for preopenFd := uintptr(3); ; preopenFd++ {
l, err := net.FileListener(os.NewFile(preopenFd, ""))
var se syscall.Errno
switch errors.As(err, &se); se {
case syscall.ENOTSOCK:
continue
case syscall.EBADF:
err = nil
}
return l, err
}
}
A similar strategy can be used with net.FileConn and pre-opened
connection sockets.
The wasmtime runtime supports pre-opening listener sockets:
$ wasmtime --tcplisten 127.0.0.1:8080 module.wasm
Change-Id: Iec6ae4ffa84b3753cce4f56a2817e150445db643
Reviewed-on: https://go-review.googlesource.com/c/go/+/493358
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Implements netpoll using WASI's poll_oneoff system call.
This enables non-blocking I/O support for wasip1.
Change-Id: Ie395fa49d651c8b8262d485e2847dd65b0a10bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/493357
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Julien Fabre <ju.pryz@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Currently /gc/scan/total:bytes is computed as a separate sum. Compute it
using the same inputs so it's always consistent with the sum of
everything else in /gc/scan/*.
For #56857.
Change-Id: I43d9148a23b1d2eb948ae990193dca1da85df8a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/497880
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
In theory by allocating new objects every time, the benchmark is
including the performance of allocating new pinner bits for a span. In
practice however, most of the time each span already does have pinner
bits allocated (it's still a rare operation).
We can get a better sense of the raw cost of pinning an object (minus
pinner bits allocation) by moving the object allocation out of the inner
loop.
Change-Id: I2869fa6c3f353b726fe8440d2e6b7f89902f9364
Reviewed-on: https://go-review.googlesource.com/c/go/+/497620
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
This test is fundamentally flaky because of a mismatch between how
internal idle time is calculated and how the test expects it to be
calculated. It's unclear how to resolve this mismatch, given that it's
perfectly valid for a goroutine to remain asleep while background
goroutines (e.g. the scavenger) run. In practice, we might be able to
set some generous lower-bound, but until we can confirm that on the
affected platforms, skip the test as flaky unconditionally.
For #60276.
For #60376.
Change-Id: Iffd5c4be10cf8ae8a6c285b61fcc9173235fbb2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/497876
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
name old time/op new time/op delta
Values-10 8.67ms ± 0% 7.19ms ± 2% -17.05% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
Values-10 58.2kB ± 2% 48.3kB ± 2% -17.14% (p=0.000 n=9+10)
name old allocs/op new allocs/op delta
Values-10 0.00 0.00 ~ (all equal)
Change-Id: Idd35ea37514a21d97bdd6191c8fb8a478c00e414
Reviewed-on: https://go-review.googlesource.com/c/go/+/481436
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: xie cui <523516579@qq.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
With the Garbage collector (GC), we observed a false-sharing between
work.full and work.empty. (referenced most from runtime.gcDrain and
runtime.getempty)
This false-sharing becomes worse and impact performance on multi core
system. On Intel Xeon 8480+ and default GC setting(GC=100), we can
observed top HITM>4% (by perf c2c)caused by it.
After resolveed this false-sharing issue, we can get performance 8%~9.7%
improved. Verify workloads:
DeathStarBench/hotelReservation: 9.7% of RPS improved
https://github.com/delimitrou/DeathStarBench/tree/master/hotelReservation
gRPC-go/benchmark: 8% of RPS improved
https://github.com/grpc/grpc-go/tree/master/benchmark
gRPC-go/benchmark 9 iterations' data with master branch:
master w/ fs opt.
208862.4 246390.9
221680.0 266019.3
223886.9 248789.7
212169.3 257837.8
219922.4 234331.8
197401.7 261627.7
214562.4 255429.7
214328.5 237087.8
229443.2 230591.3
max 229443.2 266019.3 116%
med 214562.4 248789.7 116%
avg 215806.3 248678.5 115%
Change-Id: Ib386de021cd2dbb802a107f487556d848ba9212d
Reviewed-on: https://go-review.googlesource.com/c/go/+/496915
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Currently the pinner is created outside of the benchmarking loop.
However, this means that we get to reuse the same pinner for each loop;
in general, users are expected to create a pinner for a e.g. a cgo
call and then that variable will expire with the frame it lives in. (If
they can reuse the variable, great! However, I don't expect that to be
common.)
In essence, this benchmarks a harder case. It's not more right or wrong
than the previous version, but the fact that it's a slightly harder case
(that still mostly captures what the original version was capturing) is
useful.
Change-Id: I94987127f54d7bfecd7b8e6a5e632631ea57ad24
Reviewed-on: https://go-review.googlesource.com/c/go/+/497616
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Jes Cok
Ian Lance Taylor
Dan Kortschak
Matthieu Baerts
Cherry Mui
Michael Anthony Knyszek
Keith Randall
Michael Pratt
Chris O'Hara
Hiro
Jelle van den Hooff
Olivier Mengué
Alexander Yastrebov
cui fliter
Josh Rickmar
Philip Silva
Roland Shoemaker
Austin Clements
Alessandro Arzilli
David Chase
Mark Ryan
Jonathan Amsterdam
Russ Cox
Brad Fitzpatrick
cuiweixie
Li