Michael Anthony Knyszek [Wed, 25 Jun 2025 15:47:05 +0000 (15:47 +0000)]
runtime: make explicit nil check in (*spanInlineMarkBits).init
The hugo binary gets slower, potentially dramatically so, with
GOEXPERIMENT=greenteagc. The root cause is page mapping churn. The Green
Tea code introduced a new implicit nil check on value in a
freshly-allocated span to clear some new heap metadata. This nil check
would read the fresh memory, causing Linux to back that virtual address
space with an RO page. This would then be almost immediately written to,
causing Linux to possibly flush the TLB and find memory to replace that
read-only page (likely deduplicated as just the zero page).
This CL fixes the issue by replacing the implicit nil check, which is a
memory read expected to fault if it's truly nil, with an explicit one.
The explicit nil check is a branch, and thus makes no reads to memory.
The result is that the hugo binary no longer gets slower.
No regression test because it doesn't seem possible without access to OS
internals, like Linux tracepoints. We briefly experimented with RSS
metrics, but they're inconsistent. Some system RSS metrics count the
deduplicated zero page, while others (like those produced by
/proc/self/smaps) do not.
Instead, we'll add a new benchmark to our benchmark suite, separately.
For #73581.
Fixes #74375.
Change-Id: I708321c14749a94ccff55072663012eba18b3b91
Reviewed-on: https://go-review.googlesource.com/c/go/+/684015 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
Michael Pratt [Tue, 24 Jun 2025 20:33:10 +0000 (16:33 -0400)]
runtime: note custom GOMAXPROCS even if value doesn't change
When an application calls runtime.GOMAXPROCS(runtime.GOMAXPROCS(0)), the
runtime does not need to change the actual GOMAXPROCS value (via STW).
However, this call must still transition from "automatic" to "custom"
GOMAXPROCS state, thus disabling background updates.
Thus this case shouldn't return quite as early as it currently does.
Change-Id: I6a6a636c42f73996532bd9f7beb95e933256c9e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/683815 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Joe Tsai [Mon, 4 Sep 2023 19:14:13 +0000 (12:14 -0700)]
encoding/json: use zstd compressed testdata
There is a non-public zstd decoder in the stdlib (CL 473356) and
also zstd compressed testdata already present.
Delete testdata/code.json.gz and
instead use internal/jsontest/testdata/golang_source.json.zst,
which has exactly the same content:
$ cat internal/jsontest/testdata/golang_source.json.zst | zstd -d | sha1sum 3f70b6fd429f4aba3e8e1c3e5a294c8f2e219a6e -
$ cat testdata/code.json.gz | zstd -d | sha1sum 3f70b6fd429f4aba3e8e1c3e5a294c8f2e219a6e -
This will reduce the size of the final Go release by 118KB.
Updates #71845
Change-Id: I6da2df27bd260befc0a44c6bc0255365be0a5b0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/525516
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Damien Neil <dneil@google.com>
Julien Cretel [Mon, 23 Jun 2025 16:19:19 +0000 (16:19 +0000)]
net/http: reduce allocs in CrossOriginProtection.Check
Rather than repeatedly creating error values on
CrossOriginProtection.Check's unhappy paths, return non-exported and
effectively constant error variables.
For #73626.
Change-Id: Ibaa036c29417071b3601b8d200ab0902359d1bb9
GitHub-Last-Rev: e704d63cd63665845d544796e802134ea608e217
GitHub-Pull-Request: golang/go#74251
Reviewed-on: https://go-review.googlesource.com/c/go/+/681178 Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-by: qiu laidongfeng2 <2645477756@qq.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Joe Tsai [Thu, 19 Jun 2025 01:35:36 +0000 (18:35 -0700)]
encoding/json/v2: support ISO 8601 durations
Based on the discussion in #71631, it is hotly contested
whether the default JSON representation for a Go time.Duration
should be the time.Duration.String format or
a particular profile of ISO 8601.
Regardless of the default, it seems clear that we should
at least support ISO 8601 if specified via a format flag.
Note that this CL does not alter the default representation.
Unfortunately, ISO 8601 is a large and evolving standard
with many optional extensions and optional restrictions.
Thus, the term "ISO 8601 duration" unfortunately does not
resolve to a particular grammar, nor one that is stable.
However, there is precedence that we can follow in this matter.
JSON finds its heritage in JavaScript and
JavaScript is adding a Temporal.Duration type whose default
JSON representation is ISO 8601.
There is a well-specified grammar for their particular
profile of ISO 8601, which is documented at:
https://tc39.es/proposal-temporal/#prod-Duration
This particular CL adds support for ISO 8601 according to
the exact same grammar that JavaScript uses.
While Temporal.Duration is technically still a proposal,
it is already in stage 3 of the TC39 proposal process
(i.e., "no changes to the proposal are expected"
and "has been recommended for implementation")
and therefore close to final adoption.
One major concern with ISO 8601 is that it supports
nominal date units like years, months, weeks, and days
that do not have an accurate meaning without being
anchored to a particular point in time and place on Earth.
Fortunately, JavaScript (by default) avoids producing
Temporal.Duration values with nominal units unless
arithmetic in JavaScript explicitly sets a largestUnits
value that is larger than "hours". In the Go implementation,
we support syntactically parsing the full ISO 8601 grammar
(according to JavaScript), but semantically report an error if
nominal units are present. This ensures that ISO 8601 durations
remain accurate so long as they only use the accurate units
of hours, minutes, or seconds.
Updates #71631
Change-Id: I983593662f2150461ebc486a5acfeb72f0286939
Reviewed-on: https://go-review.googlesource.com/c/go/+/682403 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
the concern was raised that whenever "-" is combined with other options,
the "-" is intepreted as as a name, rather than an ignored field,
which may go contrary to user expectation.
Static analysis demonstrates that there are ~2k instances of `json:"-,omitempty"
in the wild, where almost all of them intended for the field to be ignored.
To prevent this footgun, reject any tags that has "-," as a prefix
and warn the user to choose one of the reasonable alternatives.
The documentation of json/v2 already suggests `json:"'-'"`
as the recommended way to explicitly specify dash as the name.
See Example_fieldNames for example usages of the single-quoted literal.
Update the v1 json documentation to suggest the same thing.
Updates #71497
Change-Id: I7687b6eecdf82a5d894d057c78a4a90af4f5a6e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/683175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Joe Tsai [Tue, 17 Jun 2025 19:34:22 +0000 (12:34 -0700)]
encoding/json/v2: report error on time.Duration without explicit format
The default representation of a time.Duration is still undecided.
In order to keep the future open, report an error on a time.Duration
without an explicit format flag provided.
Updates #71631
Change-Id: I08248404ff6551723851417c8188a13f53c61937
Reviewed-on: https://go-review.googlesource.com/c/go/+/682455
Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
Joe Tsai [Mon, 23 Jun 2025 23:36:25 +0000 (16:36 -0700)]
cmd/dist: test encoding/json/... with GOEXPERIMENT=jsonv2
This also updates wasip1_wasm to use a 8MiB stack, which is
the same stack size as what is used by go_js_wasm_exec.
The increase of stack size is necessary because the jsonv2
tests exercise that the jsonv2 and jsontext packages support
a hard limit of a maximum JSON nesting depth of 10000.
However, even with a depth limit of 10000, this still exceeds
the previously specified maximum stack size of 1 MiB.
For use of JSON with untrusted inputs in WASM,
we really need to support #56733 as there is no right answer
for the default max depth limit to use since the max wasm
stack size is determined on a per-system basis.
Updates #71845
Change-Id: I3b32c58cc9f594a5c59bb3e4b20f5e86d85d8209
Reviewed-on: https://go-review.googlesource.com/c/go/+/683575 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Anthony Knyszek [Mon, 23 Jun 2025 20:14:18 +0000 (20:14 +0000)]
internal/trace: improve gc-stress test
The gc-stress test is useful for trying to exercise GC-related trace
events by producing a lot of them in many different situations.
Unfortunately this test is flaky, because allocating in a loop can
easily out-run the GC when it's trying to preempt the allocating
goroutine.
It's been a long standing problem that a program that allocates in a
loop can outrun a GC. The problem isn't the GC persay, it's consistently
correlated with a high STW time (likely a high 'stopping' time, not a
'stopped' time), suggesting that in the window of time when the garbage
collector is trying to stop all goroutines, they continue to allocate.
This should probably be fixed in general, but for now, let's focus on
this flaky test.
This CL changes the gc-stress test to (1) set a memory limit and (2) do
more work in between allocations. (2) is really what makes things less
flaky, but (2) unfortunately also means the GC is less exercised. That's
where (1) comes in. By setting a low memory limit, we increase GC
activity (in particular, assist activity). The memory limit also helps
prevent the heap from totally blowing up due to the heap goal inflating
from floating garbage, but it's not perfect.
After this change, under stress2, this test exceeds a heap size of 500
MiB only 1 in 5000 runs on my 64-vCPU VM. Before this change, it got
that big about 1/4th of the time.
Fixes #74052.
Change-Id: I49233c914c8b65b1d593d3953891fddda6685aec
Reviewed-on: https://go-review.googlesource.com/c/go/+/683515 Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Joe Tsai [Sat, 21 Jun 2025 17:51:08 +0000 (10:51 -0700)]
encoding/json/jsontext: consistently use JSON terminology
RFC 8259, section 2 uses the term "begin-array" amd "begin-object"
rather than "start array" or "start object".
Be consistent in our documentation.
Change-Id: I172eb354c5e64b84c74bd662b1e581424e719a32
Reviewed-on: https://go-review.googlesource.com/c/go/+/683155
Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Michael Pratt [Wed, 11 Jun 2025 20:46:21 +0000 (16:46 -0400)]
cmd/go/internal/fips140: ignore GOEXPERIMENT on error
During toolchain selection, the GOEXPERIMENT value may not be valid for
the current version (but it is valid for the selected version). In this
case, cfg.ExperimentErr is set and cfg.Experiment is nil.
Normally cmd/go main exits when ExperimentErr is set, so Experiment is
~never nil. But that is skipped during toolchain selection, and
fips140.Init is used during toolchain selection.
Fixes #74111.
Change-Id: I6a6a636c65ee5831feaf3d29993a60613bbec6f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/680976
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Michael Anthony Knyszek [Wed, 18 Jun 2025 17:42:16 +0000 (17:42 +0000)]
runtime: set mspan limit field early and eagerly
Currently the mspan limit field is set after allocSpan returns, *after*
the span has already been published to the GC (including the
conservative scanner). But the limit field is load-bearing, because it's
checked to filter out invalid pointers. A stale limit value could cause
a crash by having the conservative scanner access allocBits out of
bounds.
Fix this by setting the mspan limit field before publishing the span.
For large objects and arena chunks, we adjust the limit down after
allocSpan because we don't have access to the true object's size from
allocSpan. However this is safe, since we first initialize the limit to
something definitely safe (the actual span bounds) and only adjust it
down after. Adjusting it down has the benefit of more precise debug
output, but the window in which it's imprecise is also fine because a
single object (logically, with arena chunks) occupies the whole span, so
the 'invalid' part of the memory will just safely point back to that
object. We can't do this for smaller objects because the limit will
include space that does *not* contain any valid objects.
Fixes #74288.
Change-Id: I0a22e5b9bccc1bfdf51d2b73ea7130f1b99c0c7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/682655 Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
Michael Anthony Knyszek [Sat, 14 Jun 2025 02:45:08 +0000 (02:45 +0000)]
runtime: prevent mutual deadlock between GC stopTheWorld and suspendG
Almost everywhere we stop the world we casGToWaitingForGC to prevent
mutual deadlock with the GC trying to scan our stack. This historically
was only necessary if we weren't stopping the world to change the GC
phase, because what we were worried about was mutual deadlock with mark
workers' use of suspendG. And, they were the only users of suspendG.
In Go 1.22 this changed. The execution tracer began using suspendG, too.
This leads to the possibility of mutual deadlock between the execution
tracer and a goroutine trying to start or end the GC mark phase. The fix
is simple: make the stop-the-world calls for the GC also call
casGToWaitingForGC. This way, suspendG is guaranteed to make progress in
this circumstance, and once it completes, the stop-the-world can
complete as well.
We can take this a step further, though, and move casGToWaitingForGC
into stopTheWorldWithSema, since there's no longer really a place we can
afford to skip this detail.
While we're here, rename casGToWaitingForGC to casGToWaitingForSuspendG,
since the GC is now not the only potential source of mutual deadlock.
Fixes #72740.
Change-Id: I5e3739a463ef3e8173ad33c531e696e46260692f
Reviewed-on: https://go-review.googlesource.com/c/go/+/681501 Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Michael Anthony Knyszek [Mon, 16 Jun 2025 16:31:10 +0000 (16:31 +0000)]
cmd/dist: always include variant in package names
Our attempt to evenly distribute tests across shards struggles a bit
because certain long-running targets are very difficult to distinguish
in ResultDB, namely racebench and the test directory tests. These are
the only tests where the JSON output from dist omits the variant from
the package, making it impossible to distinguish them in the test result
data. My current suspicion is that this is preventing the load balancing
from being effective for the race builders in particular, though I worry
the longtest builders have a similar situation with the test directory
tests.
For #65814.
Change-Id: I5804c2af092ff9aa4a3f0f6897b4a57c4628f837
Reviewed-on: https://go-review.googlesource.com/c/go/+/681955 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Michael Anthony Knyszek [Tue, 10 Jun 2025 21:44:56 +0000 (21:44 +0000)]
runtime: don't let readTrace spin on trace.shutdown
Issue #74045 describes a scenario in which gopark is inlined into
readTrace, such that there are no preemption points. This is only a
problem because readTrace spins if trace.shutdown is set, through
traceReaderAvailable. However, trace.shutdown is almost certainly
overkill for traceReaderAvailable. The first condition, checking whether
the reader gen and the flushed gen match, should be sufficient to ensure
the reader wakes up and finishes flushing all buffers. The first
condition is also safe because it guarantees progress. In the case of
shutdown, all the trace work that will be flushed has been flushed, and
so the trace reader will exit into a regular goroutine context when
it's finished. If not shutting down, then the trace reader will release
doneSema, increase readerGen, and then the gopark unlockf will let it
block until new work actually comes in.
Fixes #74045.
Change-Id: Id9b15c277cb731618488771bd484577341b68675
Reviewed-on: https://go-review.googlesource.com/c/go/+/680738
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Michael Anthony Knyszek [Wed, 11 Jun 2025 21:35:29 +0000 (21:35 +0000)]
internal/trace: make Value follow reflect conventions
A previous change renamed Value.Uint64 to Value.ToUint64 to accomodate
string values. The method for a string value is then Value.ToString,
while the method for a debug string (for example, for fmt) is just
called String, as per fmt.Stringer.
This change follows a request from Dominik Honnef, maintainer of
gotraceui, to make Value follow the conventions of the reflect package.
The Value type there has a method String which fulfills both purposes:
getting the string for a String Value, and as fmt.Stringer. It's
not exactly pretty, but it does make sense to just stick to convention.
Change-Id: I55b364be88088d2121527bffc833ef03dbdb9764
Reviewed-on: https://go-review.googlesource.com/c/go/+/680978 Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
Alberto Donizetti [Thu, 12 Jun 2025 08:19:28 +0000 (10:19 +0200)]
all: replace a few user-visible mentions of golang.org and godoc.org
This change replaces a few user-visible mentions of golang.org and
godoc.org with go.dev and pkg.go.dev, respectively. Non-user-visible
mentions (e.g. in test scripts) were left untouched.
Change-Id: I5d828edcd618b6c55243d0dfcadc6fa1ce9422ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/681255 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Michael Anthony Knyszek [Wed, 11 Jun 2025 21:20:05 +0000 (21:20 +0000)]
internal/trace: end test programs with SIGQUIT
This change switches from using testenv.Command to
testenv.CommandContext which is a little bit friendlier. It also
switches away from using 'go run' to 'go build' and running the
resulting binary explicitly. This helps eliminate any questions about
signal handling and propagation.
For #72740.
Change-Id: Ife8010da89a7bc439e061fe0c9c6b1f5620d90f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/680977 Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Change-Id: I7b2c391749e0113e006f37b2ac1ebfe3ee0a4e0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/680715
TryBot-Bypass: Damien Neil <dneil@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Damien Neil <dneil@google.com>
David Chase [Tue, 10 Jun 2025 18:15:46 +0000 (14:15 -0400)]
cmd/compile: add up-to-date test for generated files
This runs the ssa/_gen generator writing files into
a temporary directory, and then checks that there are
no differences with what is currently in the ssa directory,
and also checks that any file with the "generated from
_gen/..." header was actually generated, and checks that
the headers on the generated file match the expected
header prefix.
Change-Id: Ic8eeb0b06cf6f2e576a013e865b331a12d3a77aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/680615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Damien Neil [Thu, 5 Jun 2025 21:27:45 +0000 (14:27 -0700)]
os: disallow Root.Remove(".") on Plan 9, js, and Windows
Windows already forbids this, since removing the root causes a
sharing violation (can't delete the directory while the os.Root
has a handle open to it), but add a more explicit check for
attempts to delete "." and return EINVAL.
Note that this change to Windows doesn't affect operations like
Root.Remove("dir/."), since the path is cleaned into just "dir"
before attempting the deletion.
Fixes #73863
Change-Id: I0f45ccb6c9f171d3a52831632c134150388d77b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/679377
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Anthony Knyszek [Tue, 10 Jun 2025 16:42:59 +0000 (16:42 +0000)]
runtime: handle system goroutines later in goroutine profiling
Before CL 650697, there was only one system goroutine that could
dynamically change between being a user goroutine and a system
goroutine, and that was the finalizer/cleanup goroutine. In goroutine
profiles, it was handled explicitly. It's status would be checked during
the first STW, and its stack would be recorded. This let the goroutine
profiler completely ignore system goroutines once the world was started
again.
CL 650697 added dedicated cleanup goroutines (there may be more than
one), and with this, the logic for finalizer goroutines no longer
scaled. In that CL, I let the isSystemGoroutine check be dynamic and
dropped the special case, but this was based on incorrect assumptions.
Namely, it's possible for the scheduler to observe, for example, the
finalizer goroutine as a system goroutine and ignore it, but then later
the goroutine profiler itself sees it as a user goroutine. At that point
it's too late and already running. This violates the invariant of the
goroutine profile that all goroutines are handled by the profiler before
they start executing. In practice, the result is that the goroutine
profiler can crash when it checks this invariant (not checking the
invariant means racily reading goroutine stack memory).
The root cause of the problem is that these system goroutines do not
participate in the goroutine profiler's state machine. Normally, when
profiling, goroutines transition from 'absent' to 'in-progress' to
'satisfied'. However with system goroutines, the state machine is
ignored entirely. They always stay in the 'absent' state. This means
that if a goroutine transitions from system to user, it is eligible for
a profile record when it shouldn't be. That transition shouldn't be
allowed to occur with respect to the goroutine profiler, because the
goroutine profiler is trying to snapshot the state of every goroutine.
The fix to this problem is simple: don't ignore system goroutines. Let
them participate in the goroutine profile state machine. Instead, decide
whether or not to record the stack after the goroutine has been acquired
for goroutine profiling. This means if the scheduler observes the
finalizer goroutine as a system goroutine, it will get promoted in the
goroutine profiler's state machine, and no other part of the goroutine
profiler will observe the goroutine again. Simultaneously, the
stack record for the goroutine will be correctly skipped.
Fixes #74090.
Change-Id: Icb9a164a033be22aaa942d19e828e895f700ca74
Reviewed-on: https://go-review.googlesource.com/c/go/+/680477 Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Damien Neil [Thu, 5 Jun 2025 20:47:06 +0000 (13:47 -0700)]
testing/synctest, runtime: avoid panic when using linker-alloc WG from bubble
We associate WaitGroups with synctest bubbles by attaching a
special to the WaitGroup. It is not possible to attach a special
to a linker-allocated value, such as:
var wg sync.WaitGroup
Avoid panicking when accessing a linker-allocated WaitGroup
from a bubble. We have no way to associate these WaitGroups
with a bubble, so just treat them as always unbubbled.
This is probably fine, since the WaitGroup was always
created outside the bubble in this case.
Fixes #74005
Change-Id: Ic71514b0b8d0cecd62e45cc929ffcbeb16f54a55
Reviewed-on: https://go-review.googlesource.com/c/go/+/679695 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Anthony Knyszek [Mon, 9 Jun 2025 22:54:54 +0000 (22:54 +0000)]
internal/trace: pass GOTRACEBACK=crash to testprogs
The failures in #70310 are hard to decipher. The cases where the lock is
being held either don't really make sense (the STW failures) or the
goroutine that fails is 'running on another thread' and we don't get a
stack trace. In fact, such a goroutine exists even in the STW cases.
Since reproducing this is going to be hard (very few failures over a 2
year span) let's set GOTRACEBACK=crash for these testprogs so next time
it happens we can see why.
For #70310.
Change-Id: I81a780aa82b173d42973f06911cb243f33352be1
Reviewed-on: https://go-review.googlesource.com/c/go/+/680476 Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
Damien Neil [Fri, 30 May 2025 21:05:10 +0000 (14:05 -0700)]
os: do not follow dangling symlinks in Root when O_CREATE|O_EXCL on AIX
OpenFile with O_CREATE|O_EXCL should not follow dangling symlinks.
On AIX it does, because AIX's openat(2) apparently returns ELOOP
in this case. Most Unices return EEXIST.
Ensure that we never follow symlinks in the final component of
the path when opening a file with O_CREATE|O_EXCL.
Fixes #73924
Change-Id: I869afb7faefccb0bb29d155553a7d7e5be80467d
Reviewed-on: https://go-review.googlesource.com/c/go/+/677735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Austin Clements [Tue, 10 Jun 2025 16:26:03 +0000 (12:26 -0400)]
net/http: make the zero value of CrossOriginProtection work
Currently, CrossOriginProtection must be constructed by
NewCrossOriginProtection. If you try to use the zero value, most
methods will panic with a nil dereference.
This CL makes CrossOriginProtection use on-demand initialization
instead, so the zero value has the same semantics as the value
currently returned by NewCrossOriginProtection. Now,
NewCrossOriginProtection just constructs the zero value.
We keep NewCrossOriginProtection by analogy to NewServeMux.
Updates #73626
Fixes #74089.
Change-Id: Ia80183eb6bfdafb0e002271c0b25c2d6230a159a
Reviewed-on: https://go-review.googlesource.com/c/go/+/680396
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
Michael Matloob [Tue, 10 Jun 2025 15:12:10 +0000 (11:12 -0400)]
cmd/dist: only install necessary tools when doing local test
Instead of installing all of cmd, install only the tools that cmd/dist
would normally install.
Also, remove the addition of the buildid tool to the list of commands in
the toolchain in debug mode. The uses of buildid were removed in CL 451360.
For #71867
Change-Id: I062909d23c18294aa23ea43b9f7eeb69bfa80c8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/680475 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Matloob <matloob@google.com>
Michael Anthony Knyszek [Mon, 9 Jun 2025 21:45:33 +0000 (21:45 +0000)]
runtime: don't do a direct G handoff in semrelease on systemstack
semrelease is safe to call on the system stack (since it just readies
goroutines) except for the fact that it might perform a direct G
handoff and call into the scheduler. If handoff is set to false this is
exceptionally rare, but could happen, and has happened for the trace
reader goroutine which releases a trace.doneSema.
Fixes #73469.
Change-Id: I37ece678bc4721bbb6e5879d74daac762b7d742a
Reviewed-on: https://go-review.googlesource.com/c/go/+/680315
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
Guoqi Chen [Mon, 9 Jun 2025 09:04:55 +0000 (17:04 +0800)]
all.{bash,rc}: use "../bin/go tool dist" instead of "%GOTOOLDIR%/dist" print build info
After CL 677558, when running all.bash, the binaries of commands such
as dist, nm, and pprof are no longer built by default, so when running
all.bash, "./all.bash: line 13: /home/golang/pkg/tool/linux_amd64/dist:
No such file or directory" will be printed, and the return result of
the all.bash script is non-zero.
Although the "dist" command won't be installed in $GOTOOLDIR anymore,
but it will be built and cached, and ../bin/go tool dist will reuse the
cached binary.
For #71867
Change-Id: I802eeafdb866e7d80c42da3e0955bb32def7b037
Reviewed-on: https://go-review.googlesource.com/c/go/+/680135 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org>
Paul Murphy [Wed, 4 Jun 2025 13:51:11 +0000 (08:51 -0500)]
cmd/compile/internal/ssa: fix PPC64 merging of (AND (S[RL]Dconst ...)
CL 622236 forgot to check the mask was also a 32 bit rotate mask. Add
a modified version of isPPC64WordRotateMask which valids the mask is
contiguous and fits inside a uint32.
I don't this is possible when merging SRDconst, the first check should
always reject such combines. But, be extra careful and do it there
too.
Fixes #73153
Change-Id: Ie95f74ec5e7d89dc761511126db814f886a7a435
Reviewed-on: https://go-review.googlesource.com/c/go/+/679775
Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Jayanth Krishnamurthy <jayanth.krishnamurthy@ibm.com> 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> Reviewed-by: Keith Randall <khr@golang.org>
Damien Neil [Fri, 6 Jun 2025 19:59:04 +0000 (12:59 -0700)]
runtime: use small struct TestSynctest to ensure cleanups run
Finalizers and cleanup funcs weren't running on the windows-arm64
builder. Put finalizers/cleanups on a small struct containing a pointer
rather than an *int, which fixes the problem.
Also uncomment a synctest.Wait that was accidentally commented out.
Fixes #73977
Change-Id: Ia6f18d74d6fccf2c5a9222317977c7458d67f158
Reviewed-on: https://go-review.googlesource.com/c/go/+/679696
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Damien Neil [Thu, 5 Jun 2025 21:21:47 +0000 (14:21 -0700)]
runtime: clarify stack traces for bubbled goroutines
Use the synctest bubble ID to identify bubbles in traces,
rather than the goroutine ID of the bubble's root goroutine.
Some waitReasons include a "(synctest)" suffix to distinguish
a durably blocking state from a non-durable one. For example,
"chan send" vs. "chan send (synctest)". Change this suffix
to "(durable)".
Always print a "(durable)" sufix for the state of durably
blocked bubbled goroutines. For example, print "sleep (durable)".
Drop the "[not] durably blocked" text from goroutine states,
since this is now entirely redundant with the waitReason.
Damien Neil [Thu, 5 Jun 2025 20:55:35 +0000 (13:55 -0700)]
runtime: return a different bubble deadlock error when main goroutine is done
The synctest.Test function waits for all goroutines in a bubble to
exit before returning. If there is ever a point when all goroutines
in a bubble are durably blocked, it panics and reports a deadlock.
Panic with a different message depending on whether the bubble's
main goroutine has returned or not. The main goroutine returning
stops the bubble clock, so knowing whether it is running or not
is useful debugging information.
The new panic messages are:
deadlock: all goroutines in bubble are blocked
deadlock: main bubble goroutine has exited but blocked goroutines remain
Change-Id: I94a69e79121c272d9c86f412c1c9c7de57ef27ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/679375
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Cuong Manh Le [Tue, 3 Jun 2025 14:35:20 +0000 (21:35 +0700)]
cmd/compile: relax reshaping condition
CL 641955 changes the Unified IR reader to not doing shapify when
reading reshaping expression. However, this condition only matters with
pointer type shaping, which will lose the original type, causes the
reshaping ends up with a completely different type.
This CL relaxes the condition, always allow non-pointer types shaping.
Updates #71184
Fixes #73947
Change-Id: Ib0bafd8932c52d99266f311b6cbfc75c00383f9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/678335 Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
Jonathan Amsterdam [Sun, 8 Jun 2025 12:49:25 +0000 (08:49 -0400)]
log/slog: fix level doc on handlers
Fixed doc on {JSON,Text}Handler.Handle: the level is never omitted.
Fixes #73943.
Change-Id: Ia470cbe5d713ab18dd80eeea1c0ab8f5e6d30f3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/680055
Auto-Submit: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Sean Liao <sean@liao.dev>
Guoqi Chen [Thu, 5 Jun 2025 11:23:55 +0000 (19:23 +0800)]
runtime: check for gsignal in racecall on loong64
This issue has been fixed for amd64, arm64 and other platforms
in CL 643875, but it was missed when the race support was
submitted for loong64.
Fixes #71395.
Change-Id: I678f381e868214f1b3399be43187db49e1660933
Reviewed-on: https://go-review.googlesource.com/c/go/+/679055 Reviewed-by: Meidan Li <limeidan@loongson.cn> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
Change-Id: I5df35f700684510328f92bb5d4946c5123ba5f2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/667757
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Carlos Amedee [Wed, 4 Jun 2025 19:35:31 +0000 (15:35 -0400)]
all: update vendored dependencies [generated]
The Go 1.25 RC is due soon. This is the time to once again update all
golang.org/x/... module versions that contribute packages to the std and
cmd modules in the standard library to latest master versions.
For #36905.
[git-generate]
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=master
cat << EOF | patch
diff --git a/src/cmd/go/testdata/script/test_json_build.txt b/src/cmd/go/testdata/script/test_json_build.txt
index df8863ae03..2a572ace72 100644
--- a/src/cmd/go/testdata/script/test_json_build.txt
+++ b/src/cmd/go/testdata/script/test_json_build.txt
@@ -56,7 +56,7 @@ stdout '"Action":"fail","Package":"m/cycle/p","Elapsed":.*,"FailedBuild":"m/cycl
! go test -json -o=$devnull ./veterror
stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-output","Output":"# m/veterror\\n"'
stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-output","Output":"# \[m/veterror\]\\n"'
-stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-output","Output":"veterror(/|\\\\)main_test.go:9:9: fmt.Printf format %s reads arg #1, but call has 0 args\\n"'
+stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-output","Output":"veterror(/|\\\\)main_test.go:9:21: fmt.Printf format %s reads arg #1, but call has 0 args\\n"'
stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-fail"'
stdout '"Action":"start","Package":"m/veterror"'
stdout '"Action":"output","Package":"m/veterror","Output":"FAIL\\tm/veterror \[build failed\]\\n"'
EOF
Change-Id: I6a8d35acdeab90c3bbd6395b8b1abb021673b5cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/678556 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Neal Patel [Wed, 21 May 2025 18:11:44 +0000 (14:11 -0400)]
net/http: strip sensitive proxy headers from redirect requests
Similarly to Authentication entries, Proxy-Authentication entries should be stripped to ensure sensitive information is not leaked on redirects outside of the original domain.
Damien Neil [Mon, 2 Jun 2025 16:26:27 +0000 (09:26 -0700)]
runtime: make bubbled timers more consistent with unbubbled
This CL makes two changes to reduce the predictability
with which bubbled timers fire.
When asynctimerchan=0 (the default), regular timers with an associated
channel are only added to a timer heap when some channel operation
is blocked on that channel. This allows us to garbage collect
unreferenced, unstopped timers. Timers in a synctest bubble, in
contrast, are always added to the bubble's timer heap.
This CL changes bubbled timers with a channel to be handled the
same as unbubbled ones, adding them to the bubble's timer heap only
when some channel operation is blocked on the timer's channel.
This permits unstopped bubbled timers to be garbage collected,
but more importantly it makes all timers past their deadline
behave identically, regardless of whether they are in a bubble.
This CL also changes timer scheduling to execute bubbled timers
immediately when possible rather than adding them to a heap.
Timers in a bubble's heap are executed when the bubble is idle.
Executing timers immediately avoids creating a predictable
order of execution.
For #73850
Fixes #73934
Change-Id: If82e441546408f780f6af6fb7f6e416d3160295d
Reviewed-on: https://go-review.googlesource.com/c/go/+/678075
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Cherry Mui [Tue, 3 Jun 2025 19:44:32 +0000 (15:44 -0400)]
Revert "cmd/compile: Enable inlining of tail calls"
This reverts CL 650455 and CL 655816.
Reason for revert: it causes #73747. Properly fixing it gets into
trickiness with defer/recover, wrapper, and inlining. We're late
in the Go 1.25 release cycle.
Fixes #73747.
Change-Id: Ifb343d522b18fec3fec73a7c886678032ac8e4df
Reviewed-on: https://go-review.googlesource.com/c/go/+/678575 Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Michael Anthony Knyszek [Tue, 3 Jun 2025 20:30:43 +0000 (20:30 +0000)]
cmd/trace: handle Sync event at the beginning of the trace
Currently the code assumes that there's no Sync event at the start of
the trace, but this hasn't been correct for some time. Count Syncs and
look for at least one instead of looking for zero.
Fixes #73962.
Change-Id: I2b4199a21c699c5b50b3d5add37dc46a515108c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/678555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Michael Anthony Knyszek [Tue, 3 Jun 2025 19:28:00 +0000 (19:28 +0000)]
runtime: reduce per-P memory footprint when greenteagc is disabled
There are two additional sources of memory overhead per P that come from
greenteagc. One is for ptrBuf, but on platforms other than Windows it
doesn't actually cost anything due to demand-paging (Windows also
demand-pages, but the memory is 'committed' so it still counts against
OS RSS metrics). The other is for per-sizeclass scan stats. However when
greenteagc is disabled, most of these scan stats are completely unused.
The worst-case memory overhead from these two sources is relatively
small (about 10 KiB per P), but for programs with a small memory
footprint running on a machine with a lot of cores, this can be
significant (single-digit percent).
This change does two things. First, it puts ptrBuf initialization behind
the greenteagc experiment, so now that memory is never allocated by
default. Second, it abstracts the implementation details of scan stat
collection and emission, such that we can have two different
implementations depending on the build tag. This lets us remove all the
unused stats when the greenteagc experiment is disabled, reducing the
memory overhead of the stats from ~2.6 KiB per P to 536 bytes per P.
This is enough to make the difference no longer noticable in our
benchmark suite.
Fixes #73931.
Change-Id: I4351f1cbb3f6743d8f5922d757d73442c6d6ad3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/678535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
qiulaidongfeng [Tue, 3 Jun 2025 15:01:27 +0000 (23:01 +0800)]
cmd/compile: better error message when import embed package
Fixes #73955
Change-Id: I7cf3ab4c70dc2e2765b54b88ae8cfc77a3073344
Reviewed-on: https://go-review.googlesource.com/c/go/+/678355
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Matloob [Fri, 30 May 2025 16:53:42 +0000 (12:53 -0400)]
cmd/dist: don't install tools that won't be shipped in distribution
We shouldn't be installing these tools because we will remove them in
distpack. Installing the tools will also prevent us from testing what
happens when the tools are missing.
The changes below this on the stack, CL 677775 (cmd/doc: build cmd/doc
directly into the go command) and CL 677636 (cmd/go/internal/cfg: fix
GOROOT setting when forcing host config) are needed for this change to
pass tests. The doc change is being done so we preserve the properties
in the tests that doc can be invoked without doing a build. It's not
strictly necessary (we could just remove the tests) but it's nice to
have. The GOROOT setting is a significant bug in switching the
configuration to host mode: the value of GOROOT wasn't being reset,
which caused issues for go commands built with trimpath, because
runtime.GOROOT wouldn't have the correct goroot value.
For #71867
Change-Id: I4181711ba117066b7d62d7d013ad4b186871cfb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/677558 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
Michael Matloob [Fri, 30 May 2025 22:20:05 +0000 (18:20 -0400)]
cmd/doc: build cmd/doc directly into the go command
There are a couple of places where our tests expect that 'go doc'
doesn't need to do a build. Invoke the cmd/doc code directly by the go
command instead of starting the doc tool in a separate process so we can
preserve that property.
This change moves most of the doc code into the package
cmd/internal/doc, and exposes a Main function from that function that's
called both by the cmd/doc package, and by go doc.
This change makes couple of additional changes to intergrate doc into
the go command:
The counter.Open call and the increment of invocations counter are only
needed by cmd/doc. The go command will open the counters file and
increment a counter for the doc subcommand.
We add a cmd_go_bootstrap tagged variant of the file that defines go doc
so that we don't end up linking net into the bootstrap version of the go
command. We don't need doc in that version of the command.
We create a new flagSet rather than using flag.CommandLine because when
running as part of the go command, the flags to "go doc" won't be the top
level flags.
We change TestGoListTest in go_test.go to use gofmt instead of doc as an
example of a main package in cmd with an in-package test.
For #71867
Change-Id: I3e3df83e5fa266559606fdc086b461165e09f037
Reviewed-on: https://go-review.googlesource.com/c/go/+/677775
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
Michael Pratt [Tue, 3 Jun 2025 17:08:06 +0000 (13:08 -0400)]
go/token: remove unreachable code
Reported by go vet.
Change-Id: I6a6a636c79923fafd8c649c583383cdf455c6ce2
Reviewed-on: https://go-review.googlesource.com/c/go/+/678317 Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Matloob [Fri, 30 May 2025 20:16:27 +0000 (16:16 -0400)]
cmd/go/internal/cfg: fix GOROOT setting when forcing host config
We manage the state using a bunch of global config, so we need to make
sure we're doing things in the right order. In this case, the SetGOROOT
function was being called in init, setting the GOROOT on the global
Context, but when we reset the context in ForceHost we lost the goroot
configuration. We need to call SetGOROOT in ForceHost to re-set the
GOROOT on the new context.
This was uncovered by CL 677558 because a go command that was built with
trimpath would try to use its runtime.GOROOT(), which wouldn't be valid
in trimpath mode. Setting GOROOT properly with SetGOROOT will use the
value from findGOROOT, assuming GOROOT isn't set in the environment,
and findGOROOT will try to determine GOROOT using the path of the go
command executable.
For #71867
Change-Id: I731b6c5d859b4504fc128b29ab904e3a2886ff3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/677636
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Keith Randall [Mon, 2 Jun 2025 23:24:07 +0000 (16:24 -0700)]
runtime: additional memmove benchmarks
For testing out duffcopy changes.
Change-Id: I93b4a52d75418a6e31aae5ad99f95d1870812b69
Reviewed-on: https://go-review.googlesource.com/c/go/+/678215 Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
Alan Donovan [Fri, 23 May 2025 02:06:13 +0000 (22:06 -0400)]
go/token: FileSet: hold Files in a balanced tree
This CL changes the representation of FileSet from a slice
to a tree, specifically an AVL tree keyed by the File's
base-end range. This makes a sequence of insertions using
AddExistingFiles much more efficient: creating a FileSet
of size n by a sequence of calls costs O(n log n), whereas
before it was O(n^2 log n) because of the repeated sorting.
The AVL tree is based on Russ' github.com/rsc/omap,
simplified for clarity and to reduce unnecessary dynamism.
We use an AVL tree as it is more strongly balanced than an
RB tree, optimising lookups at the expense of insertions.
The CL includes a basic unit test of the tree using
operations on pseudorandom values.
Benchmarks of Position lookups actually improve because
the tree avoids BinarySearchFunc's dynamic dispatch to cmp,
and the benchmark of AddExistingFiles is about 1000x (!) faster:
Damien Neil [Thu, 29 May 2025 18:48:06 +0000 (11:48 -0700)]
runtime: randomize order of timers at the same instant in bubbles
In synctest bubbles, fire timers scheduled for the same instant
in a randomized order.
Pending timers are added to a heap ordered by the timer's wakeup time.
Add a per-timer random value, set when the timer is added to a heap,
to break ties between timers scheduled for the same instant.
Only inject this randomness in synctest bubbles. We could do so
for all timers at the cost of one cheaprand call per timer,
but given that it's effectively impossible to create two timers
scheduled for the same instant outside of a fake-time environment,
don't bother.
Fixes #73876
For #73850
Change-Id: Ie96c86a816f548d4c31e4e014bf9293639155bd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/677276
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Alan Donovan [Mon, 2 Jun 2025 15:27:08 +0000 (11:27 -0400)]
slices,sort: explicitly discard results in benchmarks
The unusedresult analyzer will report failure to use the results
of these pure functions.
Updates #73950
Change-Id: I783cb92ad913105afd46c782bedf6234410c645d
Reviewed-on: https://go-review.googlesource.com/c/go/+/677995 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Commit-Queue: Alan Donovan <adonovan@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Carlos Amedee [Fri, 30 May 2025 20:05:04 +0000 (16:05 -0400)]
internal/trace: expose the go version read by the reader
This change adds a function to expose the version set by the trace
reader after reading the trace header (in tests). The trace validator
needs to be able to determine what version of the trace it needs to
validate against. Clock snapshot checks have been disabled for
Windows and WASM.
For #63185
Change-Id: Ia3d63e6ed7a5ecd87e63292b84cc417d982aaa5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/677695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Carlos Amedee <carlos@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Michael Matloob [Fri, 30 May 2025 19:23:36 +0000 (15:23 -0400)]
cmd/distpack: add test case for pack tool being excluded
For #71867
Change-Id: Ic4c6304b9a6b35c45bf35342523930924c68545a
Reviewed-on: https://go-review.googlesource.com/c/go/+/677635
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Michael Matloob [Fri, 30 May 2025 16:22:23 +0000 (12:22 -0400)]
cmd/distpack: don't keep the pack tool
This was an oversight: the pack tool isn't actually used in builds.
For #71867
Change-Id: Ib1f1cce0b574cf1d2c1002b2f2ab9ef9d750d0fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/677557 Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Cherry Mui [Thu, 29 May 2025 19:42:23 +0000 (15:42 -0400)]
cmd/compile: update default PGO profile
Since last time the default.pgo profile is collected, there has
been a lot of development in the compiler. It's time to refresh
the compiler's PGO profile.
Profile collected by running the cmd/compile/profile.sh script on
the gotip-linux-amd64_c3h88-perf_vs_release gomote.
This String method can potentially recurse infinitely, since %#x will
apparently call String if the method exists. This isn't well documented,
but cmd/vet will be updated soon to check this (when we update the
vendored x/tools dependency) so cut off the recursion by converting to
the underlying type first.
Change-Id: Ia6fc046c9eb56a5dd6a33772afd23da443a06116
Reviewed-on: https://go-review.googlesource.com/c/go/+/677261
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Damien Neil [Thu, 22 May 2025 18:14:53 +0000 (11:14 -0700)]
runtime, testing/synctest: breaking bubble isolation with Cond is fatal
sync.Cond.Wait is durably blocking. Waking a goroutine out of Cond.Wait
from outside its bubble panics.
Make this panic a fatal panic, since it leaves the notifyList in an
inconsistent state. We could do some work to make this a recoverable
panic, but the complexity doesn't seem worth the outcome.
For #67434
Change-Id: I88874c1519c2e5c0063175297a9b120cedabcd07
Reviewed-on: https://go-review.googlesource.com/c/go/+/675617
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Mark Freeman [Thu, 22 May 2025 15:06:23 +0000 (11:06 -0400)]
internal/pkgbits: explain the rationale for reference tables
The primary benefit of reference tables is to the linker, though they
are also reasonably compact as compared to absolute element indices. It
is worth also checking if reference table structure is similarly
exploited past the IR linking stage.
Ideally, the reference table definition would live in / near the linker.
As it stands, it's a bit hard to infer the purpose of the reference
tables when looking at pkgbits in isolation.
Change-Id: I496aca5a4edcf28e66fa7863ddfa4d825e1b2e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/675596
Auto-Submit: Mark Freeman <mark@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Pratt [Wed, 28 May 2025 20:01:33 +0000 (16:01 -0400)]
runtime: guarantee no GOMAXPROCS update syscalls after GOMAXPROCS call
We already guarantee that no automatic updates to GOMAXPROCS occur after
a GOMAXPROCS call returns. This is easily achieved by having the update
goroutine double-check that updates are still allowed during STW before
committing the new value.
However, it is possible for sysmon to concurrently run defaultGOMAXPROCS
to compute a new GOMAXPROCS value after GOMAXPROCS returns. This new
value will be discarded later, but we'll still perform the system calls
necessary to compute the new value.
Normally this distinction doesn't matter, but if you want to sandbox a
Go program, then you may want to disable GOMAXPROCS updates to reduce
the system call footprint. A call to GOMAXPROCS will disable updates,
but without a guarantee on when sysmon will observe the change it is
somewhat fragile.
Add explicit synchronization between GOMAXPROCS and sysmon to guarantee
that sysmon won't run defaultGOMAXPROCS after GOMAXPROCS returns.
The synchronization is a bit complex because we can't hold a mutex
across STW, nor take a semaphore from sysmon, but the result isn't too
bad.
One oddity is that sched.customGOMAXPROCS and gomaxprocs are no longer
updated in lockstep (even though both are protected by sched.lock), but
I don't believe anything should depend on that.
For #73193.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-staticlockranking
Change-Id: I6a6a636cff243a9b69ac1b5d2f98925648e60236
Reviewed-on: https://go-review.googlesource.com/c/go/+/677037
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Damien Neil [Fri, 23 May 2025 00:18:12 +0000 (17:18 -0700)]
internal/synctest: speed up TestWeak
Run TestWeak for fewer iterations. Five is enough reproduce #73817,
which was the motivation for this test. runtime.GC is ridiculously
slow on wasm, and not especially fast anywhere else.
Change-Id: Ieb5235d064b123cbc22a306425e385c273b54493
Reviewed-on: https://go-review.googlesource.com/c/go/+/675716 Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Damien Neil [Tue, 20 May 2025 22:56:43 +0000 (15:56 -0700)]
runtime, internal/synctest, sync: associate WaitGroups with bubbles
Add support to internal/synctest for managing associations between
arbitrary pointers and synctest bubbles. (Implemented internally to
the runtime package by attaching a special to the pointer.)
Associate WaitGroups with bubbles.
Since WaitGroups don't have a constructor,
perform the association when Add is called.
All Add calls must be made from within the same bubble,
or outside any bubble.
When a bubbled goroutine calls WaitGroup.Wait,
the wait is durably blocking iff the WaitGroup is associated
with the current bubble.
Change-Id: I77e2701e734ac2fa2b32b28d5b0c853b7b2825c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/676656 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Michael Pratt [Wed, 28 May 2025 18:34:52 +0000 (14:34 -0400)]
runtime: increment updatemaxprocs metric only when disabled
The updatemaxprocs metric logic is currently backwards. We only
increment the metric when we update GOMAXPROCS, but that only occurs if
updatemaxprocs is enabled.
Instead, the metric is supposed to increment when updatemaxprocs is
disabled and there would be different behavior if it were enabled.
Theoretically we should run the entire update system in a dry run mode,
and only bail out right before committing updates. But that is an awful
lot of effort for a feature that is disabled. Plus some users (like
sandboxes) want to completely disable the update syscalls
(sched_getaffinity and pread64). If we still do dry run updates then we
need an additional GODEBUG for completely disabling functionality.
This CL also avoids starting the update goroutine at all if disabled,
since it isn't needed.
For #73193.
Change-Id: I6a6a636ceec8fced44e36cb27dcb1b4ba51fce33
Reviewed-on: https://go-review.googlesource.com/c/go/+/677036 Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Alan Donovan [Wed, 21 May 2025 15:21:31 +0000 (11:21 -0400)]
go/doc: NewFromFiles: fix panic on Files with SkipObjectResolution
This CL fixes a panic in NewFromFiles when it is provided files
produced by the parser in SkipObjectResolution mode, which skips
the step of connecting ast.Idents to (deprecated) ast.Objects.
Instead of calling ast.NewPackage, which performs a number of
unnecessary steps, we just construct the ast.Package directly.
Fixes #66290
Change-Id: Id55bd30d8afb9d396c3901070e7607c5a22030d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/675036 Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Keith Randall [Thu, 29 May 2025 00:09:05 +0000 (17:09 -0700)]
cmd/compile: do nil check before calling duff functions, on arm64 and amd64
On these platforms, we set up a frame pointer record below
the current stack pointer, so when we're in duffcopy or duffzero,
we get a reasonable traceback. See #73753.
But because this frame pointer record is below SP, it is vulnerable.
Anything that adds a new stack frame to the stack might clobber it.
Which actually happens in #73748 on amd64. I have not yet come across
a repro on arm64, but might as well be safe here.
The only real situation this could happen is when duffzero or duffcopy
is passed a nil pointer. So we can just avoid the problem by doing the
nil check outside duffzero/duffcopy. That way we never add a frame
below duffzero/duffcopy. (Most other ways to get a new frame below the
current one, like async preempt or debugger-generated calls, don't
apply to duffzero/duffcopy because they are runtime functions; we're
not allowed to preempt there.)
Longer term, we should stop putting stuff below SP. #73753 will
include that as part of its remit. But that's not for 1.25, so we'll
do the simple thing for 1.25 for this issue.
Fixes #73748
Change-Id: I913c49ee46dcaee8fb439415a4531f7b59d0f612
Reviewed-on: https://go-review.googlesource.com/c/go/+/676916
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com>