This pulls in the changes to remove 1.18 support in counter and
countertest, to add counter.CountCommandLineFlags, and to add
countertest.SupportedPlatform
Commands run:
go get golang.org/x/telemetry@abedc37
go mod tidy
go mod vendor
Change-Id: I5c17c5b3ca38df14883ba43316d59437a737b28b
Reviewed-on: https://go-review.googlesource.com/c/go/+/571801
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
This usage shows up in quite a few places, and helps reduce
register pressure in several complex cryto functions by
removing a MOVD $0,... instruction.
Change-Id: I9444ea8f9d19bfd68fb71ea8dc34e109681b3802
Reviewed-on: https://go-review.googlesource.com/c/go/+/571055
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Makes the build work with CGO_CPPFLAGS=-D_GNU_SOURCE,
as reportedly used by TinyGo.
Fixes#66325
Change-Id: I794f1cd89814638fdb6c3066d13bbd7da88c9d93
Reviewed-on: https://go-review.googlesource.com/c/go/+/571875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This reverts CL 544019 and CL 569815, because they break a variety
of tests inside Google that do not expect the Cache-Control header
to be set to no-cache.
A followup CL will add this functionality back after a proposal.
For #50905.
Change-Id: Ie377bfb72ce2c77d11bf31f9617ab6db342a408a
Reviewed-on: https://go-review.googlesource.com/c/go/+/571975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Minor cleanups to CL 561635's test for better debuggability
when it crashes. In a separate CL so that it's clear this CL is
not changing the code under test.
Change-Id: I12b72ae538f8454b5c382127eafd766c22c69b67
Reviewed-on: https://go-review.googlesource.com/c/go/+/571799
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This makes CL 561635's test pass without any changes to the
traceback textual format.
The test in this CL is copied identically from CL 561635.
Change-Id: I5130abdfefd9940f98f20c283cca6cd159e37617
Reviewed-on: https://go-review.googlesource.com/c/go/+/571798
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is a partial roll-forward of CL 473495, which was subsequently
reverted. The second half of CL 473495 will appear in a future CL.
In this patch we introduce a new Go linker "-bindnow" command line
flag, and update the Go command to permit the use of the -Wl,-z,now
option, to allow users to produce binaries that have immediate
binding.
Updates #45681.
Change-Id: Idd61b0d6597bcd37b16c343714c55a4ef6dfb534
Reviewed-on: https://go-review.googlesource.com/c/go/+/571416
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
An optional interface FileInfoNames has been added.
If the parameter fi of FileInfoHeader implements the interface
the Gname/Uname of the return value Header
are provided by the method of the interface.
Also added testing.
Fixes#50102
Change-Id: I47976e238eb20ed43113b060e4f83a14ae49493e
GitHub-Last-Rev: a213613c79
GitHub-Pull-Request: golang/go#65273
Reviewed-on: https://go-review.googlesource.com/c/go/+/558355
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
"atomicPointerDedup" is a redundancy of "atomic.Pointer".
Since Go 1.22 now requires the final point release of Go 1.20 or
later for bootstrap, Go 1.19's atomic.Pointer can be used
without problems.
atomicPointerDedup is unnecessary and we can remove it now.
Change-Id: I0a65ad0b6649cecb73d58dc39c5fd736390d5fa5
GitHub-Last-Rev: 6c6e9421fb
GitHub-Pull-Request: golang/go#65987
Reviewed-on: https://go-review.googlesource.com/c/go/+/567656
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In Checker.validType, when we encounter a type parameter, we evaluate
the validity of the respective type argument in the "type nest" of the
enclosing type (at the nesting depth at which the type argument was
passed) (*). Specifically, we call validType recursively, with the slice
representing the type nest shortened by 1. This recursive call continues
to use the nest slice and in the process may overwrite the (previously)
last entry. Upon return of that recursive call, validType proceeds with
the old length, possibly using an incorrect last nest entry.
In the concrete example for this issue we have the type S
type S[T any] struct {
a T
b time.Time
}
instantiated with time.Time. When validType encounters the type parameter
T inside the struct (S is in the type nest) it evaluates the type argument
(time.Time) in the empty type nest (outside of S). In the process of
evaluating the time.Time struct, the time.Time type is appended to the
(shortened) nest slice and overwrites the previous last nest entry (S).
Once processing of T is done, validType continues with struct field b,
using the original-length nest slice, which now has time.Time rather
than S as a last element. The type of b has type time.Time, which now
appears to be nested in time.Time (rather than S), which (incorrectly)
means that there's a type cycle. validType proceeds with reporting the
error. But time.Time is an imported type, imported types are correct
(otherwise they could not be imported in the first place), and the
assertion checking that package of time.Time is local fails.
The fix is trivial: restore the last entry of the nest slice when it
may have been overwriten.
(*) In hindsight we may be able to sigificantly simplify validType by
evaluating type arguments when they are passed instead of when
the respective type parameters are encountered. For another CL.
Fixes#66323.
Change-Id: I3bf23acb8ed14d349db342ca5c886323a6c7af58
Reviewed-on: https://go-review.googlesource.com/c/go/+/571836
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
- Only search DNS servers for network interfaces with at least one gateway
- Clarify comment on deprecated site local anycast fec0/10 DNS IPv6 addresses
- Minor maintenance: skip not "up" interfaces earlier in outer loop
Change-Id: I98ca7b81d3d51e6aa6bfa4a10dcd651305a843df
GitHub-Last-Rev: 3b358c7e3f
GitHub-Pull-Request: golang/go#64441
Reviewed-on: https://go-review.googlesource.com/c/go/+/545775
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
With this change my test program that reads a tree of ELF files runs
1.71 ± 0.12 times faster without parallelism or 1.39 ± 0.06 times
faster using 8 goroutines.
Change-Id: I443d1a02736f16f5532ef28e1447c97aa87c7126
Reviewed-on: https://go-review.googlesource.com/c/go/+/571436
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Go 1.13 is not supported anymore, but this CL removes an unnecessary
check and in turn fixes an old bug.
Fixes#66285.
Change-Id: I15ee1712b31f8ac8c915f18410d99cbf44334d35
Reviewed-on: https://go-review.googlesource.com/c/go/+/571058
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This is a cherry-pick of CL 571075 combined with adjustments for 1.23:
Imported interfaces don't have position information for embedded types.
When computing the type set of such interfaces, doing a version check
may fail because it will rely on the Go version of the current package.
We must not do a version check for features of types from imported
packages - those types have already been typechecked and are "correct".
The version check code does look at packages to avoid such incorrect
version checks, but we don't have the package information available
in an interface type (divorced from its object).
Instead, rely on the fact that imported interfaces don't have position
information for embedded types: if the position is unknown, don't do a
version check.
In Checker.allowVersion, still allow for unknown positions and resort
to the module version in that case (source code may be generated by
tools and not contain position information). Also, remove the *Package
argument as it was always check.pkg except in one case, and that case
may in fact be incorrect; treat that case separately for now.
Fixes#66064.
Change-Id: I773d57e5410c3d4a911ab3e018b3233c2972b3c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/571075
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/571137
Still investigating, but adding the minimized reproducer as a regress
test case for now.
Updates #66261.
Change-Id: I20715b731f8c5b95616513d4a13e3ae083709031
Reviewed-on: https://go-review.googlesource.com/c/go/+/571815
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The purpose of this package is to have a build tagged variant so that
when we're building the bootstrap go command it does not depend on the
net package. (net is a dependency of golang.org/x/telemetry/counter on
Windows).
The TESTGO_TELEMETRY_DIR environment variable used by the go tests to
change the telemetry directory is renamed to TEST_TELEMETRY_DIR to
make it more general to other commands that might want to set it for
the purpose of tests. The test telemetry directory is now set using
telemetry.Start instead of countertest.Open. This also means that the
logic that decides whether to upload counter files is now going to run
from the cmd/go tests (but that's okay because it's aleady been
running when cmd/go has been invoked outside of its tests.
Change-Id: Ic4272e5083facde010482d8b8fc3c95c03564bc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/571096
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Change-Id: Ic7b390935df107c5b7f53f9347a52031eac8a897
GitHub-Last-Rev: a7194571e1
GitHub-Pull-Request: golang/go#66310
Reviewed-on: https://go-review.googlesource.com/c/go/+/571635
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This reverts commit 643d816c8b (CL 561635).
Reason for revert: This works for telemetry but broke various other
properties of the tracebacks as well as some programs that read
tracebacks. We should figure out a solution that works for all uses,
and in the interim we should not be making telemetry work at the
cost of breaking other, existing valid uses.
See #65761 for details.
Change-Id: I467993ae778887e5bd3cca4c0fb54e9d44802ee1
Reviewed-on: https://go-review.googlesource.com/c/go/+/571797
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A proposal discussion in mid-2020 on #37196 decided to change
time.Timer and time.Ticker so that their Stop and Reset methods
guarantee that no old value (corresponding to the previous configuration
of the Timer or Ticker) will be received after the method returns.
The trivial way to do this is to make the Timer/Ticker channels
unbuffered, create a goroutine per Timer/Ticker feeding the channel,
and then coordinate with that goroutine during Stop/Reset.
Since Stop/Reset coordinate with the goroutine and the channel
is unbuffered, there is no possibility of a stale value being sent
after Stop/Reset returns.
Of course, we do not want an extra goroutine per Timer/Ticker,
but that's still a good semantic model: behave like the channels
are unbuffered and fed by a coordinating goroutine.
The actual implementation is more effort but behaves like the model.
Specifically, the timer channel has a 1-element buffer like it always has,
but len(t.C) and cap(t.C) are special-cased to return 0 anyway, so user
code cannot see what's in the buffer except with a receive.
Stop/Reset lock out any stale sends and then clear any pending send
from the buffer.
Some programs will change behavior. For example:
package main
import "time"
func main() {
t := time.NewTimer(2 * time.Second)
time.Sleep(3 * time.Second)
if t.Reset(2*time.Second) != false {
panic("expected timer to have fired")
}
<-t.C
<-t.C
}
This program (from #11513) sleeps 3s after setting a 2s timer,
resets the timer, and expects Reset to return false: the Reset is too
late and the send has already occurred. It then expects to receive
two values: the one from before the Reset, and the one from after
the Reset.
With an unbuffered timer channel, it should be clear that no value
can be sent during the time.Sleep, so the time.Reset returns true,
indicating that the Reset stopped the timer from going off.
Then there is only one value to receive from t.C: the one from after the Reset.
In 2015, I used the above example as an argument against this change.
Note that a correct version of the program would be:
func main() {
t := time.NewTimer(2 * time.Second)
time.Sleep(3 * time.Second)
if !t.Reset(2*time.Second) {
<-t.C
}
<-t.C
}
This works with either semantics, by heeding t.Reset's result.
The change should not affect correct programs.
However, one way that the change would be visible is when programs
use len(t.C) (instead of a non-blocking receive) to poll whether the timer
has triggered already. We might legitimately worry about breaking such
programs.
In 2020, discussing #37196, Bryan Mills and I surveyed programs using
len on timer channels. These are exceedingly rare to start with; nearly all
the uses are buggy; and all the buggy programs would be fixed by the new
semantics. The details are at [1].
To further reduce the impact of this change, this CL adds a temporary
GODEBUG setting, which we didn't know about yet in 2015 and 2020.
Specifically, asynctimerchan=1 disables the change and is the default
for main programs in modules that use a Go version before 1.23.
We hope to be able to retire this setting after the minimum 2-year window.
Setting asynctimerchan=1 also disables the garbage collection change
from CL 568341, although users shouldn't need to know that since
it is not a semantically visible change (unless we have bugs!).
As an undocumented bonus that we do not officially support,
asynctimerchan=2 disables the channel buffer change but keeps
the garbage collection change. This may help while we are
shaking out bugs in either of them.
Fixes#37196.
[1] https://github.com/golang/go/issues/37196#issuecomment-641698749
Change-Id: I8925d3fb2b86b2ae87fd2acd055011cbf7bd5916
Reviewed-on: https://go-review.googlesource.com/c/go/+/568341
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Mention that the allocation counter doesn't count allocations made using
C.malloc (cgo) or in C.
Change-Id: I03c23b6d8cfde68c04a75732a0d3c05eedae2276
GitHub-Last-Rev: 2d805b3322
GitHub-Pull-Request: golang/go#65430
Reviewed-on: https://go-review.googlesource.com/c/go/+/560397
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Change-Id: I56ca2d11637d60c6b0656fdc1d900a2384aba141
GitHub-Last-Rev: 686e02db77
GitHub-Pull-Request: golang/go#66264
Reviewed-on: https://go-review.googlesource.com/c/go/+/570916
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I783e02e215efaebf4936146c6aaa032634fdfa64
GitHub-Last-Rev: 24680a73ee
GitHub-Pull-Request: golang/go#66304
Reviewed-on: https://go-review.googlesource.com/c/go/+/571595
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The OID type is not exported data like most of the other x509 structs.
Using it in x509.Certificate made Certificate not gob-compatible anymore,
which breaks real-world code. As a temporary fix, make gob ignore
that field, making it work as well as it did in Go 1.21.
For Go 1.23, we anticipate adding a proper fix and removing the gob
workaround. See #65633 and #66249 for more details.
For #66249.
Fixes#65633.
Change-Id: Idd1431d15063b3009e15d0565cd3120b9fa13f61
Reviewed-on: https://go-review.googlesource.com/c/go/+/571095
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This reverts commit a46285f8c2 (CL 469935).
Reason for revert: This breaks a variety of code inside Google
that seem representative of possible external real-world usage.
If we roll this forward again we should include a GODEBUG like
urljoinpathslash=0 to go back to the old behavior.
Change-Id: I6cd8e9888a0c088669dc5634418372252289e074
Reviewed-on: https://go-review.googlesource.com/c/go/+/571655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
This reverts https://go.dev/cl/c/go/+/473495.
Reason for revert: breaks some Google-internal tests.
This revert will be temporary until we can gather more info on the
nature of the failures and hopefully develop an upstream test case,
etc.
Updates #45681.
Change-Id: Ib628ddc53bc5489e4f76c0f4ad809b75e899102c
Reviewed-on: https://go-review.googlesource.com/c/go/+/571415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: I331c46083e9608227615183ba7e25f6299669341
GitHub-Last-Rev: 0cb78ae1c1
GitHub-Pull-Request: golang/go#66305
Reviewed-on: https://go-review.googlesource.com/c/go/+/571536
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
This reverts commit 2b58355ef6.
Reason for revert: This breaks tons of tests for no real reason.
Change-Id: I89773f48cf983c0b6346e46c37a0ebbe2620e3b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/571675
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Classic operating system kernel mistake: if you start using
per-CPU data without disabling interrupts on the CPU,
and then an interrupt reschedules the process onto a different
CPU, now you're using the wrong CPU's per-CPU data.
The same thing happens in Go if you use per-M or per-P
data structures while not holding a lock nor using acquirem.
In the original timer.modify before CL 564977, I had been
very careful about this during the "unlock t; lock ts" dance,
only calling releasem after ts was locked. That made sure
we used the right ts. The refactoring of that code into its
own helper function in CL 564977 missed that nuance.
The code
ts := &getg().m.p.p.ptr().timers
ts.lock()
was now executing without holding any locks nor acquirem.
If the goroutine changed its M or P between deciding which
ts to use and actually locking that ts, the code would proceed
to add the timer t to some other P's timers. If the P was idle
by then, the scheduler could have already checked it for timers
and not notice the newly added timer when deciding when the
next timer should trigger.
The solution is to do what the old code correctly did, namely
acquirem before deciding which ts to use, rather than assume
getg().m.p won't change before ts.lock can complete.
This CL does that.
Before CL 564977,
stress ./time.test -test.run='ZeroTimer/impl=(func|cache)' -test.timeout=3m -test.count=20
ran without failure for over an hour on my laptop.
Starting in CL 564977, it consistently failed within a few minutes.
After this CL, it now runs without failure for over an hour again.
Fixes#66006.
Change-Id: Ib9e7ccaa0f22a326ce3fdef2b9a92f7f0bdafcbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/571196
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This reverts commit 28e0052ee7.
Reason for revert: #66261
Change-Id: I9dfc8946c41e504c97ecad752971d760ae7a7416
Reviewed-on: https://go-review.googlesource.com/c/go/+/571555
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The tests analyser reports structural problems in test
declarations. Presumably most of these would be caught by
go test itself, which compiles and runs (some subset of) the
tests, but Benchmark and Fuzz functions are executed less
frequently and may benefit more from static checks.
Also, reflect the change in go test help message.
+ release note
Fixesgolang/go#44251
Change-Id: If5b9dee6d18fa0bc4de7f5f5f549eddeae953fc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/529816
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Add support for traces from Go 1.11–1.19 by converting old traces to the
Go 1.22 format on the fly.
We import Gotraceui's trace parser, which is an optimized parser based
on Go 1.19's internal/trace package, and further modify it for the needs
of the conversion process.
With the optimized parser, loading old traces using the new API is twice
as fast and uses less total memory than 'go tool trace' did in older
versions.
The new parser does not, however, support traces from versions older
than 1.11.
This commit does not update cmd/trace to use the new API for old traces.
Change-Id: If9380aa515e29445ff624274d1760ee945ca4816
Reviewed-on: https://go-review.googlesource.com/c/go/+/557356
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
From the beginning of Go, the time package has had a gotcha:
if you use a select on <-time.After(1*time.Minute), even if the select
finishes immediately because some other case is ready, the underlying
timer from time.After keeps running until the minute is over. This
pins the timer in the timer heap, which keeps it from being garbage
collected and in extreme cases also slows down timer operations.
The lack of garbage collection is the more important problem.
The docs for After warn against this scenario and suggest using
NewTimer with a call to Stop after the select instead, purely to work
around this garbage collection problem.
Oddly, the docs for NewTimer and NewTicker do not mention this
problem, but they have the same issue: they cannot be collected until
either they are Stopped or, in the case of Timer, the timer expires.
(Tickers repeat, so they never expire.) People have built up a shared
knowledge that timers and tickers need to defer t.Stop even though the
docs do not mention this (it is somewhat implied by the After docs).
This CL fixes the garbage collection problem, so that a timer that is
unreferenced can be GC'ed immediately, even if it is still running.
The approach is to only insert the timer into the heap when some
channel operation is blocked on it; the last channel operation to stop
using the timer takes it back out of the heap. When a timer's channel
is no longer referenced, there are no channel operations blocked on
it, so it's not in the heap, so it can be GC'ed immediately.
This CL adds an undocumented GODEBUG asynctimerchan=1
that will disable the change. The documentation happens in
the CL 568341.
Fixes#8898.
Fixes#61542.
Change-Id: Ieb303b6de1fb3527d3256135151a9e983f3c27e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/512355
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Comparing BenchmarkStop against very old commits like
CL 13094043, I was very confused about how timers had
gotten almost 10X slower since 2013.
It turns out that CL 68060043 introduced a factor of 1000
in the benchmark cost, by counting batches of 1000 as 1 op
instead of 1000 ops, and timers have actually gotten
dramatically faster since 2013, with the addition of per-P
timer heaps and other optimizations.
This CL rewrites the benchmarks to use testing.PB directly,
so that the factor of 1000 disappears, and "/op" really means "/op".
In the few tests that need to run in batches for one reason or
another, add "1000" to the name to make clear that batches
are being run.
Change-Id: I27ed74d1e420934982e4205aad4f218cdfc42509
Reviewed-on: https://go-review.googlesource.com/c/go/+/570495
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fixes#66215
Change-Id: Id7de15feabe08f66c048dc114c09494813c9febc
Reviewed-on: https://go-review.googlesource.com/c/go/+/570695
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Primarily, this change removes the cmd/ prefix on the go command
counter names. The 'error' counter is changed to 'errors' reflecting
that it's a bucket that contains multiple errors. the switch-exec and
select-exec counters are moved into a 'toolchain' grouping.
For #58894
Change-Id: Id6e0e7a0b4a5e42a0aef04b1210d2bb5256eb6c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/570736
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Toggled by a compile-time const, so there should be no
runtime footprint in ordinary builds.
Change-Id: I7751847524f4fda3853388d3e5a18188bd737c27
Reviewed-on: https://go-review.googlesource.com/c/go/+/570336
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
The timers had evolved to the point where the state was stored as follows:
if timer in heap:
state has timerHeaped set
if heap timer is stale:
heap deadline in t.when
real deadline in t.nextWhen
state has timerNextWhen set
else:
real deadline in t.when
t.nextWhen unset
else:
real deadline in t.when
t.nextWhen unset
That made it hard to find the real deadline and just hard to think about everything.
The new state is:
real deadline in t.when (always)
if timer in heap:
state has timerHeaped set
heap deadline in t.whenHeap
if heap timer is stale:
state has timerModified set
Separately, the 'state' word itself was being used as a lock
and state bits because the code started with CAS loops,
which we abstracted into the lock/unlock methods step by step.
At this point, we can switch to a real lock, making sure to
publish the one boolean needed by timers fast paths
at each unlock.
All this simplifies various logic considerably.
Change-Id: I35766204f7a26d999206bd56cc0db60ad1b17cbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/570335
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
https://logs.chromium.org/logs/golang/buildbucket/cr-buildbucket/8753622336585847105/+/u/step/11/log/2
shows a staticlockranking crash with pollcache (defaulted to LEAF)
being held during a write barrier, which got unlucky and acquired
wbufSpans, triggering a lock ordering throw.
My change in https://go-review.googlesource.com/c/go/+/570335/13/src/runtime/netpoll.go
around line 700 caused batching of many write barriers on the first
call rather than having just a few write barriers on each call,
making the crash much more likely, but the ordering problem
appears to have always existed. We just never allocated enough
pollDescs to trigger it.
Change-Id: Icb5e8340a5027dd4f7535a5ef02b2868476539e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/571195
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
For GOPPC64 < 10 targets, most large 32 bit constants (those
exceeding int16 capacity) can be added using two instructions
instead of 3.
This cannot be done for values greater than 0x7FFF7FFF, so this
must be done during asm preprocessing as the optab matching
rules cannot differentiate this special case.
Likewise, constants 0x8000 <= x < 0x10000 are not converted. The
assembler currently generates 2 instructions sequences for these
constants.
Change-Id: I1ccc839c6c28fc32f15d286b2e52e2d22a2a06d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/568116
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When an opcode generates a known high bit state (typically, a sub-word
operation that zeros the high bits), we can remove any subsequent
extension operation that would be a no-op.
x = (OP ...)
y = (ZeroExt32to64 x)
If OP zeros the high 32 bits, then we can replace y with x, as the
zero extension doesn't do anything.
However, x in this situation normally has a sub-word-sized type. The
semantics of values in registers is typically that the high bits
beyond the value's type size are junk. So although the opcode
generating x *currently* zeros the high bits, after x is rewritten to
another opcode it may not - rewrites of sub-word-sized values can
trash the high bits.
To fix, move the extension-removing rules to late lower. That ensures
that their arguments won't be rewritten to change their high bits.
I am also worried about spilling and restoring. Spilling and restoring
doesn't preserve the high bits, but instead sets them to a known value
(often 0, but in some cases it could be sign-extended). I am unable
to come up with a case that would cause a problem here, so leaving for
another time.
Fixes#66066
Change-Id: I3b5c091b3b3278ccbb7f11beda8b56f4b6d3fde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/568616
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
windows.SupportUnixSocket is currently implemented using a Windows
version check. This approach is not reliable, see #27943 and #28061.
Also, it uses the undocumented RtlGetNtVersionNumbers API, which
we should try to avoid.
This PR implements SupportUnixSocket by enumerating the available
protocols and checking for AF_UNIX support.
Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64
Change-Id: I76cd635067309f09571ad0eac4a5699450a2709a
Reviewed-on: https://go-review.googlesource.com/c/go/+/570075
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
