These files are not formatted by gofmt. Thus, run gofmt to format them.
Change-Id: Iea9650e64b1f47cf82739f3a8a34f47740a96455
Reviewed-on: https://go-review.googlesource.com/c/go/+/570398
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
For consistency with all.bat: "%GOTOOLDIR%/dist" banner
Fixes#66061
Change-Id: I3387003a77a5fe82fe132e7aba472b06dd9068f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/570395
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: I33858efc00dff02432f28f1e5a94aeea261a5bad
GitHub-Last-Rev: 98861f8d6e
GitHub-Pull-Request: golang/go#66230
Reviewed-on: https://go-review.googlesource.com/c/go/+/570357
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I9886a99f730b7616f6f8a5e6154e1beb7d3c79e6
GitHub-Last-Rev: 3f9dc77073
GitHub-Pull-Request: golang/go#66242
Reviewed-on: https://go-review.googlesource.com/c/go/+/570535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
On Go 1.21+ it's an error for a workspace to contain a module with a
version newer than the workspace's stated go version. If the workspace
doesn't explicitly have a go version it's explicitly 1.18. So if a
workspace without a go directive contains a module whose go directive
is newer on it's always an error for 1.21+. In the error, before this
CL the error would read "module <path> listed in go.work requires go
>= <version>, but go.work lists go 1.18". After this change the second
clause would read "but go.work implicitly requires go 1.18.
Fixes#66207
Change-Id: I44680880162a82e5cee9cfc8655d6774add6f762
Reviewed-on: https://go-review.googlesource.com/c/go/+/570735
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This matches the net/http API.
Updates #59473.
Change-Id: I99917cef3ed42a0b4a2b39230b492be00da8bbfd
Reviewed-on: https://go-review.googlesource.com/c/go/+/548355
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Extend the net/http Transport to recognize the 'socks5h' schema as an
alias for 'socks5'. Traditionally, the 'socks5h' schema indicates that
the hostname should be resolved by the proxy server, which is behavior
already implemented in Go for 'socks5'.
Fixes#24135
Change-Id: I0a6a92bbd282a3200dc4dc7b47a9b0628f931783
Reviewed-on: https://go-review.googlesource.com/c/go/+/569977
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Change-Id: I1dbd1c5aa26f458cdac7a3f0ca974254a069311f
GitHub-Last-Rev: da481ba7a9
GitHub-Pull-Request: golang/go#66219
Reviewed-on: https://go-review.googlesource.com/c/go/+/569897
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: I12bc9287106f1492cbc9e74b4163cce97c957d31
GitHub-Last-Rev: cda1b48fe3
GitHub-Pull-Request: golang/go#66185
Reviewed-on: https://go-review.googlesource.com/c/go/+/569896
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: Ic8b06c6fd9fc6a30b26f4e4614aa40b5cad3a5e7
GitHub-Last-Rev: 8397a8b30c
GitHub-Pull-Request: golang/go#66240
Reviewed-on: https://go-review.googlesource.com/c/go/+/570515
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>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: Ib44e9e6345fa8df7f46bc9cbdc19ad8ba73c8b83
GitHub-Last-Rev: 5a37ad7988
GitHub-Pull-Request: golang/go#66233
Reviewed-on: https://go-review.googlesource.com/c/go/+/570415
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: Icbf295e668335945084616a88c3ea2cef1bb2527
GitHub-Last-Rev: 0341d0fea7
GitHub-Pull-Request: golang/go#66229
Reviewed-on: https://go-review.googlesource.com/c/go/+/570356
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: I39917b90b67f630f8212853c0a201635960275cb
GitHub-Last-Rev: fe886534b4
GitHub-Pull-Request: golang/go#66180
Reviewed-on: https://go-review.googlesource.com/c/go/+/569975
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>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
go install golang.org/x/tools/cmd/bundle@latest
go generate net/http
This fixes the longtest builders, which broke at CL 570156.
Change-Id: I85e6a1c20bd0080228400a561efd750342ae2d67
Reviewed-on: https://go-review.googlesource.com/c/go/+/570276
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
OpenBSD enables Indirect Branch Tracking (IBT) on amd64 and Branch Target
Identification (BTI) on arm64, where hardware permits. Since Go generated
binaries do not currently support IBT or BTI, temporarily mark them with
PT_OPENBSD_NOBTCFI which prevents branch target CFI from being enforced
on execution. This should be removed as soon asn IBT and BTI support are
available.
Fixes#66040
Updates #66054
Change-Id: I91ac05736e6942c54502bef4b8815eb8740d2d5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/568435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Josh Rickmar <jrick@zettaport.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
GODEBUG affects test execution but was not being tracked.
Fixes#66213.
Fixes#65436.
Change-Id: I3ac3c397f0c6fa46cd9be0d22d03020d0632f64f
Reviewed-on: https://go-review.googlesource.com/c/go/+/570259
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
The simulators are too slow.
Change-Id: I0aaf2304ad0881c74886ff3185c09614de2aae63
Reviewed-on: https://go-review.googlesource.com/c/go/+/570236
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
A few recent godebugs are missing IncNonDefault uses.
Test for that, so that people remember to do it.
Filed bugs for the missing ones.
For #66215.
For #66216.
For #66217.
Change-Id: Ia3fd10fd108e1b003bb30a8bc2f83995c768fab6
Reviewed-on: https://go-review.googlesource.com/c/go/+/570275
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Telemetry counters writing is disabled on certain platforms.
See x/telemetry/internal/telemetry.DisabledOnPlatform.
For #66205
Change-Id: I833e15ae33fb27e09d67fc77b921498476237176
Reviewed-on: https://go-review.googlesource.com/c/go/+/570196
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
If user code has two timers t1 and t2 and does *t1 = *t2
(or *t1 = Timer{}), it creeps me out that we would be
corrupting the runtime data structures inlined in the
Timer struct. Replace that field with a pointer to the
runtime data structure instead, so that the corruption
cannot happen, even in a badly behaved program.
In fact, remove the struct definition entirely and linkname
a constructor instead. Now the runtime can evolve the struct
however it likes without needing to keep package time in sync.
Also move the workaround logic for #21874 out of
runtime and into package time.
Change-Id: Ia30f7802ee7b3a11f5d8a78dd30fd9c8633dc787
Reviewed-on: https://go-review.googlesource.com/c/go/+/568339
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: Ib24841f4823c357ddeefa28435c2b80867d752d2
GitHub-Last-Rev: b0c6c58b24
GitHub-Pull-Request: golang/go#66182
Reviewed-on: https://go-review.googlesource.com/c/go/+/570015
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commands run (in both src and src/cmd):
go get golang.org/x/net@master
go mod tidy
go mod vendor
For #24135
Change-Id: I88084d174c15a65350be1b43e27de619dc6d4dd6
Reviewed-on: https://go-review.googlesource.com/c/go/+/570156
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: 胡玮文 <huww98@outlook.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
An upcoming CL will give this call more to do.
For now, separate out the compiler change that
stops inlining the computation.
For #37196.
Change-Id: I965426d446964b9b4958e4613246002a7660e7eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/568375
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Ticker.Reset was added in CL 217362 in 2020.
It added the runtime helper modTimer, which is
analogous to startTimer and resetTimer but for tickers.
Unlike those, it does not contain a racerelease, which
means that code synchronizing by starting a ticker
will be diagnosed with a spurious race.
Add racerelease to modTimer and add tests of all
three racereleases (in startTimer, resetTimer, and modTimer).
Also do not call time.resetTimer from elsewhere in runtime,
since that function is only for package time. Use t.reset instead.
For #33184.
Change-Id: Ie40c1ad24911f21e81b1d3cc608cf086ff2bc83d
Reviewed-on: https://go-review.googlesource.com/c/go/+/568340
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
allp < timers has not been necessary since CL 258303.
sched < timers was implied by allp < timers, and that
was still necessary, but only when the world is stopped.
Rewrite the code to avoid that lock since the world is stopped.
Now timers and timer are independent of the scheduler,
so they could call into the scheduler (for example to ready
a goroutine) if we wanted them to.
Change-Id: I12a93013c98e51c9e2f2148175b02afce8384a59
Reviewed-on: https://go-review.googlesource.com/c/go/+/568337
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Before CL 564118, there were two ways to add a new timer:
addtimer or modtimer. Much code was duplicated between them
and it was always valid to call modtimer instead of addtimer
(but not vice versa), so that CL changed all addtimer call sites
to use modtimer and deleted addtimer.
One thing that was unique to addtimer, however, was that it
called cleantimers (now named ts.cleanHead) after locking the
timers, while modtimer did not. This was the only difference
in the duplicated code, and I missed it. Restore the call to
ts.cleanHead when adding a new timer.
Also fix double-unlock in cleanHead.
Change-Id: I26cc50d650f31f977c0c31195cd013244883dba9
Reviewed-on: https://go-review.googlesource.com/c/go/+/568338
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The comment in updateTimerPMask is wrong. It says:
// Looks like there are no timers, however another P
// may be adding one at this very moment.
// Take the lock to synchronize.
This was my incorrect simplification of the original comment
from CL 264477 when I was renaming all the things it mentioned:
// Looks like there are no timers, however another P may transiently
// decrement numTimers when handling a timerModified timer in
// checkTimers. We must take timersLock to serialize with these changes.
updateTimerPMask is being called by pidleput, so the P in question
is not in use. And other P's cannot add to this P.
As the original comment more precisely noted, the problem was
that other P's might be calling timers.check, which updates ts.len
occasionally while ts is locked, and one of those updates might
"leak" an ephemeral len==0 even when the heap is not going to
be empty when the P is finally unlocked. The lock/unlock in
updateTimerPMask synchronizes to avoid that. But this defeats
most of the purpose of using ts.len in the first place.
Instead of requiring that synchronization, we can arrange that
ts.len only ever shows a "publishable" length, meaning the len(ts.heap)
we leave behind during ts.unlock.
Having done that, updateTimerPMask can be inlined into pidleput.
The big comment on updateTimerPMask explaining how timerpMask
works is better placed as the doc comment for timerpMask itself,
so move it there.
Change-Id: I5442c9bb7f1473b5fd37c43165429d087012e73f
Reviewed-on: https://go-review.googlesource.com/c/go/+/568336
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
No semantic changes here.
Cleaning up for next change.
Change-Id: I9706009739677ff9eb893bcc007d805f7877511e
Reviewed-on: https://go-review.googlesource.com/c/go/+/568335
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
windows.Version is just a thin wrapper around RtlGetNtVersionNumbers,
which is an undocumented Windows API.
This CL unexports windows.Version so it is harder to use by accident.
Change-Id: Ib782da04e4e8be66970111a75f5c2df27ef51643
Reviewed-on: https://go-review.googlesource.com/c/go/+/570055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Many of the tests in package time are about proper manipulation
of the timer heap. But now NewTimer bypasses the timer heap
except when something is blocked on the associated channel.
Make the tests test the heap again by using AfterFunc instead of
NewTimer.
In particular, adds a non-chan version of TestZeroTimer, which
was flaky-broken and then fixed by CLs in the cleanup stack.
This new tests makes sure we notice if it breaks again.
Fixes#66006.
Change-Id: Ib59fc1b8b85ef5a21e72fe418c627c9b8b8a083a
Reviewed-on: https://go-review.googlesource.com/c/go/+/568255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The timer zombie count was fundamentally racy and worked around
in CL 569995. We worked around that by ignoring underflow.
The fundamnental race was because t.ts was set before t was
inserted into ts. CL 564997 corrected that fundamental problem,
so now we can account for zombies completely accurately,
never seeing values less than zero. Do that.
Change-Id: Idfbccc6662af5935f29f2a06a35e8ea93929bed7
Reviewed-on: https://go-review.googlesource.com/c/go/+/569996
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
timers.wakeTime, which is called concurrently by P's trying to decide
how long they should sleep, can return inaccurate values while
timers.adjust is running. (Before the refactoring, this was still true
but the code did not have good names and was spread across more
files, making the race harder to see.)
The runtime thread sleeping code is complex enough that I am not
confident that the inaccuracy can cause delayed timer wakeups,
but I am also not confident that it can't, nor that it won't in the future.
There are two parts to the fix:
1. A simple logic change in timers.adjust.
2. The introduction of t.maybeAdd to avoid having a t that is
marked as belonging to a specific timers ts but not present
in ts.heap. That was okay before when everything was racy
but needs to be eliminated to make timers.adjust fully consistent.
The cost of the change is an extra CAS-lock operation on a timer add
(close to free since the CAS-lock was just unlocked) and a change
in the static lock ranking to allow malloc while holding a timer lock.
Change-Id: I1249e6e24ae9ef74a69837f453e15b513f0d75c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/564977
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>
Writes to timers.len are protected by the timers.lock.
There is no need to use an Add instead of a Store,
and the code is clearer (and perhaps slightly faster)
using the Store.
Change-Id: Icc6caef1b7405adec55c9b55b999b71de7d97484
Reviewed-on: https://go-review.googlesource.com/c/go/+/564976
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>
These names were copied over from the p field names,
but now that they are part of the timers type they can use
shorter names that make the relationship clearer.
timer0When -> minWhen
timerModifiedEarliest -> minNextWhen
This code change is only the renaming.
Change-Id: I1c0adc0b3a1289d35639619d5c945585b2d81a9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/564975
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>
The value produced for the EvFrequency event on Windows is missing the
fact that the cputicks clock gets divided. This results in durations
that are consistently wrong by the same factor (about 256).
Fixes#65997.
Change-Id: I930cbfce3499d435c20699f41c11e3227d84f911
Reviewed-on: https://go-review.googlesource.com/c/go/+/567937
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Right now, we're careful to clean up dead P state when we advance to
future trace generations. If we don't, then if that P comes back to
life, we might end up using its old stale trace state.
Unfortunately, we never handled this in the case when tracing stops,
only when advancing to new generations. As a result, stopping a trace,
starting it again, and then bringing a P back to life in the following
generation meant that the dead P could be using stale state.
Fixes#65318.
Change-Id: I9297d9e58a254f2be933b8007a6ef7c5ec3ef4f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/567077
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
This change cleans up the ordering interface in several ways.
First, it resolves a TODO about using a proper queue of events for extra
events produced while performing ordering. This will be necessary for a
follow-up change to handle coroutine switch events.
Next, it simplifies the ordering.advance method's signature by not
returning a schedCtx. Instead, ordering.advance will take responsibility
for constructing the final Event instead of the caller, and places it on
its own internal queue (in addition to any other Events generated). The
caller is then responsible for taking events off of the queue with a new
method Next.
Finally, hand-in-hand with the signature change, the implementation of
ordering.advance no longer forces each switch case to return but instead
has them converge past the switch. This has two effects. One is that we
eliminate the deferred call to update the M state. Using a defer here is
technically incorrect, because we might end up changing the M state even
if we don't advance the event! We got lucky here that curCtx == newCtx
in all such cases, but there may have been a subtle bug lurking here.
Unfortunately because of the queue's semantics however, we can't
actually avoid pushing into the queue at every possible successful exit
out of the switch. Hopefully this can become less error-prone in the
future by splitting up the switch into a dispatch of different
functions, instead of everything living in one giant function. This
cleanup will happen in a follow-up change.
Change-Id: Ifebbbf14e8ed5c08be5c1b0fadc2e5df3915c656
Reviewed-on: https://go-review.googlesource.com/c/go/+/565936
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Tracing is currently broken when using iter.Pull from the rangefunc
experiment partly because the "tracing is off" fast path in traceAcquire
was deemed too expensive to check (an atomic load) during the coroutine
switch.
This change adds trace.enabled, a non-atomic indicator of whether
tracing is enabled. It doubles trace.gen, which is the source of truth
on whether tracing is enabled. The semantics around trace.enabled are
subtle.
When tracing is enabled, we need to be careful to make sure that if gen
!= 0, goroutines enter the tracer on traceAcquire. This is enforced by
making sure trace.enabled is published atomically with trace.gen. The
STW takes care of synchronization with most Ms, but there's still sysmon
and goroutines exiting syscalls. We need to synchronize with those
explicitly anyway, which luckily takes care of trace.enabled as well.
When tracing is disabled, it's always OK for trace.enabled to be stale,
since traceAcquire will always double-check gen before proceeding.
For #61897.
Change-Id: I47c2a530fb5339c15e419312fbb1e22d782cd453
Reviewed-on: https://go-review.googlesource.com/c/go/+/565935
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The current implementation sets t.ts before adding t to ts;
that can cause inconsistencies with temporarily negative
ts.zombies values. Handle them gracefully, since we only
care about detecting very positive values.
Pending CL 564977 removes the race that sets t.ts early,
and then CL 569996 builds on top of that to make the count precise.
This CL just gets examples like the new test working sooner.
Change-Id: Ibe1aecc2554f83436f761f48e4050bd962982e4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/569995
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This reverts commit 8a0fbd75a5.
Reason for revert: Breaking real-world tests inside Google,
which means it probably breaks real-world tests outside Google.
One instance I have seen is a <!-- --> comment (often a copyright notice) before the procinst.
Another test checks that a canonicalizer can handle a test input that simply has procinsts mid-XML.
XML is full of contradictions, XML implementations more so. If we are going to start being picky, that probably needs to be controlled by a GODEBUG (and a proposal).
For #65691 (will reopen manually).
Change-Id: Ib52d0944b1478e71744a2a35b271fdf7e1c972ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/570175
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
A Path that starts with / is absolute.
A Path that starts with any other character is relative.
The meaning of a Path of "" is not defined,
but RequestURI converts a "" Path to "/"
and an empty Path may represent a URL with just
a hostname and no trailing / such as "http://localhost".
Handle empty paths in the base URL of JoinPath consistently with
RequestURI, so that joining to an empty base produces an absolute
path rather than a relative one.
u, _ := url.Parse("http://localhost")
u = u.JoinPath("x")
fmt.Println(u.Path) // "/x", not "x"
Fixes#58605
Change-Id: Iacced9c173b0aa693800dd01caf774f3f9a66d56
Reviewed-on: https://go-review.googlesource.com/c/go/+/469935
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
As CL 569755 did, for consistency, this CL slightly improves
the documentation for RuneLen.
Change-Id: Ic9776648baf2809af36cd16a94d1313938bb0e52
Reviewed-on: https://go-review.googlesource.com/c/go/+/569816
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
CL 541715 added an optimization to copy SSA-able variables.
When handling m[k] = append(m[k], ...) case, it uses ir.SameSafeExpr to
check that m[k] expressions are the same, then doing type assertion to
convert the map index to ir.IndexExpr node. However, this assertion is
not safe for m[k] expression in append(m[k], ...), since it may be
wrapped by ir.OCONVNOP node.
Fixing this by un-wrapping any ir.OCONVNOP before doing type assertion.
Fixes#66096
Change-Id: I9ff7165ab97bc7f88d0e9b7b31604da19a8ca206
Reviewed-on: https://go-review.googlesource.com/c/go/+/569716
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Transport getConn creates wantConn w, tries to obtain idle connection for it
based on the w.key and, when there is no idle connection, puts wantConn into
idleConnWait wantConnQueue.
Then getConn dials connection for w in a goroutine and blocks.
After dial succeeds getConn unblocks and returns connection to the caller.
At this point w is stored in the idleConnWait and will not be evicted
until another wantConn with the same w.key is requested or alive
connection returned into the idle pool which may not happen e.g. if
server closes the connection.
The problem is that even after tryDeliver succeeds w references
persistConn wrapper that allocates bufio.Reader and bufio.Writer and
prevents them from being garbage collected.
To fix the problem this change removes persistConn and error references
from wantConn and delivers them via channel to getConn.
This way wantConn could be kept in wantConnQueues arbitrary long.
Fixes#43966Fixes#50798
Change-Id: I77942552f7db04c225fb40d770b3101a8cfe655d
GitHub-Last-Rev: 027a0833f9
GitHub-Pull-Request: golang/go#62227
Reviewed-on: https://go-review.googlesource.com/c/go/+/522095
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Change-Id: I0e55dd68d92c39aba511b55368bf50d929d75f86
GitHub-Last-Rev: 1743014078
GitHub-Pull-Request: golang/go#66158
Reviewed-on: https://go-review.googlesource.com/c/go/+/569696
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
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>
Change-Id: I83c23ae0933f6abe4c07144f69c3d9c18aece6e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/569175
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
