David Finkel [Fri, 14 Nov 2025 02:16:43 +0000 (21:16 -0500)]
cmd/go: support sha1 repos when git default is sha256
When git is recent enough (beyond 2.29), always set the --object-format
flag.
This fixes repo cloning when users have set the git configuration
init.defaultObjectFormat to sha256.
Git is planning[1] to switch the default hash function to sha256 with
the 3.0 release sometime in late 2026. (that may slip, but it's still
worth being ahead of the curve)
This change moves the version-check function from cl/698835 into
codehost/git.go so we can use it to condition setting
--object-format=sha1.
Adjust the regexp parsing git version output to handle more cases.
Jonathan Hall [Mon, 8 Jul 2024 16:14:43 +0000 (18:14 +0200)]
database/sql: don't ignore ColumnConverter for unknown input count
In the case a sql driver implements the ColumnConverter interface and also
returns -1 for NumInputs, indicating an unknown number of input arguments to
a query, the previous implementation would ignore the column converter would
not be called, leading to unexpected or invalid arguments passed to the driver.
Fixes #68342
Change-Id: Ib2ddaf040fa9be669d593eacdaa1e88ba66d7bc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/597115 Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Nick Ripley [Fri, 21 Nov 2025 16:01:29 +0000 (16:01 +0000)]
runtime/pprof: remove hard-coded sleep in CPU profile reader
The CPU profiler reader goroutine has a hard-coded 100ms sleep between
reads of the CPU profile sample buffer. This is done because waking up
the CPU profile reader is not signal-safe on some platforms. As a
consequence, stopping the profiler takes 200ms (one iteration to read
the last samples and one to see the "eof"), and on many-core systems the
reader does not wake up frequently enought to keep up with incoming
data.
This CL removes the sleep where it is safe to do so, following a
suggestion by Austin Clements in the comments on CL 445375. We let the
reader fully block, and wake up the reader when the buffer is over
half-full.
Fixes #63043
Updates #56029
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-arm64-longtest,gotip-linux-386-longtest
Change-Id: I9f7e7e9918a4a6f16e80f6aaf33103126568a81f
Reviewed-on: https://go-review.googlesource.com/c/go/+/610815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
Nick Ripley [Fri, 21 Nov 2025 14:09:57 +0000 (14:09 +0000)]
runtime: fix double wakeup in CPU profile buffer
The profBuf.wakeupExtra method wakes up the profile reader if it's
sleeping, either when the buffer is closed or when there is a pending
overflow entry. Unlike in profBuf.write, profBuf.wakeupExtra does not
clear the profReaderSleeping bit before doing the wakeup. As a result,
if there are two writes to a full buffer before the sleeping reader has
time to wake up, we'll see two consecutive calls to notewakeup, which is
a fatal error. This CL updates profBuf.wakeupExtra to clear the sleeping
bit before doing the wakeup.
This CL adds a unit test that demonstrates the problem. This is
theoretically possible to trigger for real programs as well, but it's
more difficult. The profBufWordCount is large enough that it takes
several CPU-seconds to fill up the buffer. So we'd need to run on a
system with lots of cores to have a chance of running into this failure,
and the reader would need to fully go to sleep before a large burst of
CPU activity.
Change-Id: I59b4fa86a12f6236890b82cd353a95706a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/722940
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
This CL implements this initial design of testing.B.Loop's keep variable
alive semantic:
https://github.com/golang/go/issues/61515#issuecomment-2407963248.
Fixes #73137.
Change-Id: I8060470dbcb0dda0819334f3615cc391ff0f6501
Reviewed-on: https://go-review.googlesource.com/c/go/+/716660
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
Sean Liao [Sat, 15 Nov 2025 23:58:58 +0000 (23:58 +0000)]
net/http: use HTTP 307 redirects in ServeMux
Clients receiving an HTTP 301 Moved Permanently may conservatively
change the method of a POST request to GET.
The newer HTTP 307 Temporary Redirect and 308 Permanent Redirect
explicitly allows retrying POST requests after the redirect.
These should be safe for ServeMux as this internal redirect is generated
before user provided handlers are called.
As ServeMux is making the redirect for the user without explicit
direction, and clients may cache Permanent Redirects indefinitely,
Temporary Redirect is used in case the user adds a handler for a path,
that was previously redirected but no longer should.
Fixes #50243
Fixes #60769
Change-Id: I6c0b735bab03bb7b50f05457b3b8a8ba813badb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/720820
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
Daniel McCarney [Tue, 11 Nov 2025 19:41:43 +0000 (14:41 -0500)]
crypto/internal/fisp140test: update acvptool, test data
This commit updates the BoringSSL module version used for the acvptool,
as well as the module version used for the static test data used by our
CI process to avoid interacting with a live ACVP server.
Two important upstream changes of note:
1. NIST changed the ML-KEM format slightly, and the BoringSSL acvptool
was updated in turn. We need to update the go-acvp data version to
one where I've regenerated the corresponding vector/expected files to
match these changes. Otherwise, we see an error from an empty dk
value.
2. The upstream BoringSSL acvptool switched to no longer truncating MAC
output in the subprocess handler for HMAC tests. Instead of relying on
this, we switch our capabilities to describe the output length we
return natively. In turn, we need to update the go-acvp data version
to vectors generated with the updated capabilities. Otherwise, we see
an error from the acvptool that our module wrapper returned a result
of the wrong length.
Change-Id: I1def172585ced0aaf1611d82f2e2802ca1500390
Reviewed-on: https://go-review.googlesource.com/c/go/+/719780
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Sean Liao [Mon, 17 Nov 2025 21:16:06 +0000 (21:16 +0000)]
runtime: remove linkname for gopanic
github.com/goplus/igop now renamed github.com/goplus/ixgo
already requires checklinkname=0, so the special case can be removed.
https://github.com/goplus/ixgo/tree/e0d0bfeb2de9cfbe0b6cd668f015a1ba35dfea76/ixgo
go.undefinedlabs.com is no longer a resolvable domain,
having been absorbed by Datadog. The original use in
https://pkg.go.dev/go.undefinedlabs.com/scopeagent@v0.4.2/reflection
probably shouldn't have qualified anyway with 0 known importers.
For #67401
Change-Id: Ida6024e014f3304d4a4190f0bd9d12746a29b40b
Reviewed-on: https://go-review.googlesource.com/c/go/+/721300 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I1d9393cd19a0b948a5d3a512d627cdc0cf0b38be
Reviewed-on: https://go-review.googlesource.com/c/go/+/721520 Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Ian Lance Taylor [Mon, 3 Nov 2025 23:54:39 +0000 (15:54 -0800)]
cmd/cgo: strip top-level const qualifier from argument frame struct
Otherwise we can't assign to it.
Fixes #75751
Change-Id: Iba680db672297bca1a1d1a33912b80863da66a08
Reviewed-on: https://go-review.googlesource.com/c/go/+/717342 Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Sean Liao [Wed, 22 Oct 2025 12:13:51 +0000 (13:13 +0100)]
errors: add examples for custom Is/As matching
Change-Id: Ia92dae13b6a4e9434b29d2ab3f698f6ba87b4b89
Reviewed-on: https://go-review.googlesource.com/c/go/+/713740 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Change-Id: Id0b3770da69c6f666b3ff36741f75377001466c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/675335
Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Ch1n-ch1nless [Fri, 21 Nov 2025 09:58:40 +0000 (12:58 +0300)]
cmd/compile/internal/ssa: correct type of ARM64 conditional instructions
The CCMP, CCMN, CCMPconst, and related instructions in ARM64Ops.go
were incorrectly set to type "Flag". This non-existent type caused
compilation failures during the "lower" and "late lower" passes.
Change them to the correct type, "Flags".
Change-Id: I4fbf96b8c7b051be901711948028a717ce953e5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/722780 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
Dmitri Shuralyov [Fri, 14 Nov 2025 18:00:28 +0000 (13:00 -0500)]
cmd/internal/objabi: remove -V=goexperiment internal special case
This special case was added in CL 310171 for test/run.go use, as the
comment still says, but run.go (cmd/internal/testdir/testdir_test.go
by now) stopped using this in CL 310732. There don't seem to be any
other internal or external uses of this special case, so delete it.
Doing this kind of a cleanup can become harder as more time passes,
so try it as early as now and see how it goes.
Change-Id: Ib52aac51ef05166f7349cfc7d63b860a8ece7ec0
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/720620
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Jakub Ciolek [Wed, 19 Nov 2025 10:17:47 +0000 (11:17 +0100)]
cmd/compile: fix integer overflow in prove pass
The detectSliceLenRelation function incorrectly deduced lower bounds
for "len(s) - i" without checking if the subtraction could overflow
(e.g. when i is negative). This led to incorrect elimination of
bounds checks.
Fixes: #76355
Change-Id: I30ada0e5f1425929ddd8ae1b66e55096ec209b5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/721920
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com>
WANG Xuerui [Mon, 6 Oct 2025 10:09:14 +0000 (18:09 +0800)]
cmd/link: support loading R_LARCH_PCREL20_S2 and R_LARCH_CALL36 relocs
Host libgcc.a (among other libraries) on loong64 systems may contain
such relocs if built with the "medium" code model and/or linker
relaxation, which is increasingly the case. Make the internal linker
aware of these for cgo interopability going forward.
While at it, fix some of the comments for the loong64-specific
RelocTypes.
Fixes #75562
Change-Id: I0810969dcd229c5131ef06b0f70f51d81a3be4cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/709717 Reviewed-by: abner chenc <chenguoqi@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Meidan Li <limeidan@loongson.cn> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Damien Neil [Sat, 8 Nov 2025 19:22:59 +0000 (11:22 -0800)]
crypto/tls: add QUICErrorEvent
Add a new QUICEvent type for reporting errors.
This provides a way to report errors that don't occur as a result of
QUICConn.Start, QUICConn.HandleData, or QUICConn.SendSessionTicket.
Fixes #75108
Change-Id: I941371a21f26b940e75287a66d7e0211fc0baab1
Reviewed-on: https://go-review.googlesource.com/c/go/+/719040
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Nicholas S. Husin [Wed, 19 Nov 2025 22:10:02 +0000 (17:10 -0500)]
net/http/httputil: wrap ReverseProxy's outbound request body so Close is a noop
Within ReverseProxy, we are currently sending a clone of our inbound
request (from client) as our outbound request (to upstream). However,
the clone of the request has a shallow copy of the request body. As a
result, when the outbound request body is closed, the inbound request
body (i.e. the outbound request body of the client) will also be closed.
This causes an unfortunate effect where we would infinitely hang when a
client sends a request with a 100-continue header via a ReverseProxy,
but the ReverseProxy fails to make a connection to the upstream server.
When this happens, the ReverseProxy's outbound request body would be
closed, which in turns also closes the client's request body.
Internally, when we close a request body, we would try to consume and
discard the content. Since the client has yet to actually send the body
content (due to 100-continue header) though, an infinite hang occurs.
To prevent this, we make sure that closing an outbound request body from
a ReverseProxy is a noop.
For #75933
Change-Id: I52dc7247f689f35a6e93d1f32b2d003d90e9d2c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/722160 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Pratt [Thu, 20 Nov 2025 21:21:09 +0000 (16:21 -0500)]
runtime: track goroutine location until actual STW
TestTraceSTW / TestTraceGCSTW currently tracks the location (M/P) of the
target goroutines until it reaches the "start" log message, assuming the
actual STW comes immediately afterwards.
On 386 with TestTraceGCSTW, it actually tends to take >10ms after the
start log before the STW actually occurs. This is enough time for sysmon
to preempt the target goroutines and migration them to another location.
Fix this by continuing tracking all the way until the STW itself occurs.
We still keep the start log message so we can ignore any STW (if any)
before we expect.
Cq-Include-Trybots: luci.golang.try:gotip-linux-386-longtest,gotip-linux-amd64-longtest
Change-Id: I6a6a636cf2dcb18d8b33ac4ad88333cabff2eabb
Reviewed-on: https://go-review.googlesource.com/c/go/+/722520 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This causes the go1.26 vet printf analyzer to deduce printf
wrappers via interface methods (#76368).
For #76368
Change-Id: I80e6d3b21bdffb5d925a162af7c4b21b1357bb89
Reviewed-on: https://go-review.googlesource.com/c/go/+/722540
Auto-Submit: Alan Donovan <adonovan@google.com>
Commit-Queue: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Keith Randall [Thu, 20 Nov 2025 18:37:10 +0000 (10:37 -0800)]
runtime: disable stack allocation tests on sanitizers
CL 707755 broke the asan/msan builders.
Change-Id: Ic9738140999a9bcfc94cecfe0964a5f1bc243c56
Reviewed-on: https://go-review.googlesource.com/c/go/+/722480
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com>
Damien Neil [Wed, 19 Nov 2025 23:32:04 +0000 (15:32 -0800)]
net/url: permit colons in the host of postgresql:// URLs
PostgreSQL's postgresql:// URL scheme permits a comma-separated list of
host:ports to appear in the host subcomponent:
https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-MULTIPLE-HOSTS
While this is not compliant with RFC 3986, it's something we've accepted
for a long time. Continue to accept colons in the host when the URL
scheme is "postgresql".
Fixes #75859
Change-Id: Iaa2e82b0be11d8e034e10dd7f4d6070039acfa2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/722300 Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Sean Liao <sean@liao.dev>
calling context.Cause(ctx) after serveGroup.Wait() will return either
"interrupt signal received" (if that happens first) or the error from
serveGroup.
Change-Id: Ie181f5f84269f6e39defdad2d5fd8ead6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/721700
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commit-Queue: Junyang Shao <shaojunyang@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Damien Neil [Wed, 19 Nov 2025 22:35:20 +0000 (14:35 -0800)]
net/http: drop unused "broken" field from persistConn
Change-Id: Ic65cf98c090c73299b5e88e642e91139315d8e52
Reviewed-on: https://go-review.googlesource.com/c/go/+/722221
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org>
Cherry Mui [Wed, 19 Nov 2025 22:32:12 +0000 (17:32 -0500)]
cmd/internal/obj/x86: handle global reference in From3 in dynlink mode
In dynlink mode, we rewrite reference to a global variable to
a load from the GOT. Currently this code does not handle the case
that the global reference is in From3 of a Prog. Most instructions
don't expect a memory operand in From3, but some do, like
VGF2P8AFFINEQB. Handle this case.
Robert Griesemer [Tue, 18 Nov 2025 23:47:44 +0000 (15:47 -0800)]
spec: adjust rule for type parameter on RHS of alias declaration
Per discussion on issue #75885, a type parameter on the RHS of an alias
declaration must not be declared in the same declaration (but it may be
declared by an enclosing function). This relaxes the spec slightly and
allows for (pre-existing) test cases.
Add a corresponding check to the type checker (there was no check for
type parameters on the RHS of alias declarations at all, before).
Fixes #75884.
Fixes #75885.
Change-Id: I1e5675978e6423d626c068829d4bf5e90035ea82
Reviewed-on: https://go-review.googlesource.com/c/go/+/721820
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Damien Neil [Wed, 19 Nov 2025 19:25:49 +0000 (11:25 -0800)]
net/http: correctly close fake net.Conns
Fix an inverted test in fakeNetConn.Close that caused closing
a connection to not break the other half of the connection.
Change-Id: I4e53f78402f8e503c749d57f294a4524abdccfb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/722220 Reviewed-by: Nicholas Husin <nsh@golang.org> Reviewed-by: Nicholas Husin <husin@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
cmd/compile: stack allocate backing stores during append
We can already stack allocate the backing store during append if the
resulting backing store doesn't escape. See CL 664299.
This CL enables us to often stack allocate the backing store during
append *even if* the result escapes. Typically, for code like:
func f(n int) []int {
var r []int
for i := range n {
r = append(r, i)
}
return r
}
the backing store for r escapes, but only by returning it.
Could we operate with r on the stack for most of its lifeime,
and only move it to the heap at the return point?
The current implementation of append will need to do an allocation
each time it calls growslice. This will happen on the 1st, 2nd, 4th,
8th, etc. append calls. The allocations done by all but the
last growslice call will then immediately be garbage.
We'd like to avoid doing some of those intermediate allocations
if possible. We rewrite the above code by introducing a move2heap
operation:
func f(n int) []int {
var r []int
for i := range n {
r = append(r, i)
}
r = move2heap(r)
return r
}
Using the move2heap runtime function, which does:
move2heap(r):
If r is already backed by heap storage, return r.
Otherwise, copy r to the heap and return the copy.
Now we can treat the backing store of r allocated at the
append site as not escaping. Previous stack allocation
optimizations now apply, which can use a fixed-size
stack-allocated backing store for r when appending.
See the description in cmd/compile/internal/slice/slice.go
for how we ensure that this optimization is safe.
Change-Id: I81f36e58bade2241d07f67967d8d547fff5302b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/707755 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Pratt [Mon, 17 Nov 2025 21:08:21 +0000 (16:08 -0500)]
runtime: select GC mark workers during start-the-world
When the GC starts today, procresize and startTheWorldWithSema don't
consider the additional Ps required to run the mark workers. procresize
and startTheWorldWithSema resume only the Ps necessary to run the normal
user goroutines.
Once those Ps start, findRunnable and findRunnableGCWorker determine
that a GC worker is necessary and run the worker instead, calling wakep
to wake another P to run the original user goroutine.
This is unfortunate because it disrupts the intentional placement of Ps
on Ms that procresize does. It also has the unfortunate side effect of
slightly delaying start-the-world time, as it takes several sequential
wakeps to get all Ps started.
To address this, procresize explicitly assigns GC mark workers to Ps
before starting the world. The assignment occurs _after_ selecting
runnable Ps, so that we prefer to select Ps that were previously idle.
Note that if fewer than 25% of Ps are idle then we won't be able to
assign all dedicated workers, and some of the Ps intended for user
goroutines will convert to dedicated workers once they reach
findRunnableGCWorker.
Also note that stack scanning temporarily suspends the goroutine. Resume
occurs through ready, which will move the goroutine to the local runq of
the P that did the scan. Thus there is still a source of migration at
some point during the GC.
For #65694.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a636c51f39f4f4bc716aa87de68f6ebe163a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/721002
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Michael Pratt [Mon, 17 Nov 2025 20:09:50 +0000 (15:09 -0500)]
runtime: split findRunnableGCWorker in two
The first part, assignWaitingGCWorker selects a mark worker (if any) and
assigns it to the P. The second part, findRunnableGCWorker, is
responsible for actually marking the worker as runnable and updating the
CPU limiter.
The advantage of this split is that assignWaitingGCWorker is safe to do
during STW, which will allow the next CL to make selections during
procresize.
This change is a semantic no-op in preparation for the next CL.
For #65694.
Change-Id: I6a6a636c8beb212185829946cfa1e49f706ac31a
Reviewed-on: https://go-review.googlesource.com/c/go/+/721001 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>
Dmitri Shuralyov [Fri, 14 Nov 2025 20:40:43 +0000 (15:40 -0500)]
go/version: use "custom" as an example of a version suffix
The suffix in a non-standard toolchain version can be any string. Show
more of a middle ground example of a non-standard version suffix,
aligning it with the example used at https://go.dev/doc/toolchain#name.
For #75953.
Change-Id: I98f9c4de98316aecf76c017eb13cf25582c8939c
Reviewed-on: https://go-review.googlesource.com/c/go/+/720621 Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: I88d7b6ae2f6fc3f095979f24fb83ff42a9d2d42e
Reviewed-on: https://go-review.googlesource.com/c/go/+/720940 Reviewed-by: Meidan Li <limeidan@loongson.cn> Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Mark Freeman [Wed, 19 Nov 2025 20:10:24 +0000 (15:10 -0500)]
go/types, types2: fix object path for grouped declaration statements
CL 715840 deferred popping from the object path during handling of
grouped declaration statements, which leaves extra objects on the
path since this executes in a loop.
Surprisingly, no test exercised this. This change fixes this small
bug and adds a supporting test.
Fixes #76366
Change-Id: I7fc038b39d3871eea3e60855c46614b463bcfa4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/722060 Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Srinivas Pokala [Fri, 14 Nov 2025 13:21:37 +0000 (14:21 +0100)]
math: switch s390x math.Pow to generic implementation
The s390x assembly implementation of math.Pow incorrectly handles
certain subnormal cases. This change switches the function to use the
generic implementation instead.
Updates #76247
Cq-Include-Trybots: luci.golang.try:gotip-linux-s390x
Change-Id: I794339080d5a7acf79bbffaeb0214809006fd30c
Reviewed-on: https://go-review.googlesource.com/c/go/+/720540 Reviewed-by: Vishwanatha HD <vishwanatha.hd@ibm.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Kiran M Vijay IBM <kiran.m.vijay@ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
Austin Clements [Tue, 10 Jun 2025 23:19:08 +0000 (19:19 -0400)]
runtime: add hexdumper
Currently, we have a simple hexdumpWords facility for debugging. It's
useful but pretty limited.
This CL adds a much more configurable and capable "hexdumper". It can
be configured for any word size (including bytes), handles unaligned
data, includes an ASCII dump, and accepts data in multiple slices. It
also has a much nicer "mark" facility for annotating the hexdump that
isn't limited to a single character per word.
We use this to improve our existing hexdumps, particularly the new
mark facility. The next CL will integrate hexdumps into debuglog,
which will make use of several other new capabilities.
The header gives column labels, indicating the order of bytes within
the following words. The addresses on the left are always 16-byte
aligned so it's easy to combine that address with the column header to
determine the full address of a byte. Annotations are no longer
interleaved with the data, so the data stays in nicely aligned
columns. The annotations are also now much more flexible, including
support for multiple annotations on the same word (not shown).
Change-Id: I27e83800a1f6a7bdd3cc2c59614661a810a57d4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/681375 Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
Reason for revert: the old behavior seems to be relied on by current
users, e.g.
https://github.com/connectrpc/connect-go/blob/cb2e11fb88c9a61804043355a619c12d4a30a1a5/protocol_connect.go#L837.
For #75933
Change-Id: I996280238e5c70a8d760a0b31e3a13c6a44b8616
Reviewed-on: https://go-review.googlesource.com/c/go/+/721761
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Nicholas Husin <nsh@golang.org> Reviewed-by: Nicholas Husin <husin@google.com>
Cherry Mui [Mon, 17 Nov 2025 22:27:21 +0000 (17:27 -0500)]
cmd/link: align sections, not symbols after DWARF compress
After DWARF compression, we recompute the symbol and section
addresses. On Windows, we need to align the sections to
PEFILEALIGN. But the code actually apply the alignment to every
symbol. This works mostly fine as after compression a section
usually contains a single symbol (the compressed data). But if the
compression is not beneficial, it leaves with the original set of
symbols, which could be more than one. Applying alignment to every
symbol causing the section size too big, no longer matching the
size we computed before compression.
Fixes #76022.
Change-Id: I2246045955405997c77e54001bbb83f9ccd1ee7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/721340
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
Youlin Feng [Wed, 29 Oct 2025 05:11:48 +0000 (13:11 +0800)]
runtime: do not print recovered when double panic with the same value
Show the "[recovered, repanicked]" message only when it is repanicked
after recovered. For the duplicated panics that not recovered, do not
show this message.
Fixes #76099
Change-Id: I87282022ebe44c6f6efbe3239218be4a2a7b1104
Reviewed-on: https://go-review.googlesource.com/c/go/+/716020
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Joel Sing [Thu, 25 Sep 2025 19:05:49 +0000 (05:05 +1000)]
cmd/asm,cmd/compile,cmd/internal/obj/riscv: use compressed instructions on riscv64
Make use of compressed instructions on riscv64 - add a compress
pass to the end of the assembler, which replaces non-compressed
instructions with compressed alternatives if possible.
Provide a `compressinstructions` compiler and assembler debug
flag, such that the compression pass can be disabled via
`-asmflags=all=-d=compressinstructions=0` and
`-gcflags=all=-d=compressinstructions=0`. Note that this does
not prevent the explicit use of compressed instructions via
assembly.
Note that this does not make use of compressed control transfer
instructions - this will be implemented in later changes.
Reduces the text size of a hello world binary by ~121KB
and reduces the text size of the go binary on riscv64 by ~1.21MB
(between 8-10% in both cases).
Updates #71105
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I24258353688554042c2a836deed4830cc673e985
Reviewed-on: https://go-review.googlesource.com/c/go/+/523478 Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Joel Sing [Sun, 27 Aug 2023 09:35:33 +0000 (19:35 +1000)]
cmd/internal/sys,internal/goarch,runtime: enable the use of compressed instructions on riscv64
Enable the use of compressed instructions on riscv64 by reducing
the PC quantum to two bytes and reducing the minimum instruction
length to two bytes. Change gostartcall on riscv64 to land at
two times the PC quantum into goexit, so that we retain four byte
alignment and revise the NOP instructions in goexit to ensure that
they are never compressed. Additionally, adjust PCALIGN so that it
correctly handles two byte offsets.
Fixes #47560
Updates #71105
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I4329a8fbfcb4de636aadaeadabb826bc22698640
Reviewed-on: https://go-review.googlesource.com/c/go/+/523477 Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
WANG Xuerui [Sat, 13 Sep 2025 07:57:12 +0000 (15:57 +0800)]
debug/elf: sync new loong64 relocation types up to LoongArch ELF psABI v20250521
Add several new relocation types defined in newer versions of LoongArch
ELF psABI v20250521, part of the v2.40 spec bundle. The new relocations
are seeing increased adoption because distributions are moving to newer
GNU/LLVM toolchain versions, so Go's internal linker must be prepared to
handle some of them, especially R_LARCH_CALL36 because the ecosystem is
slowly migrating to the "medium" code model by default.
The constants R_LARCH_DELETE and R_LARCH_CFA were removed in LoongArch
ELF psABI v20231102 (spec bundle v2.20), but they are already part of
the public API, so they are retained for now for upholding the go1
compatibility guarantee.
Nick Ripley [Mon, 17 Nov 2025 16:47:20 +0000 (11:47 -0500)]
runtime: clear frame pointer at thread entry points
There are a few places in the runtime where new threads enter Go code
with a possibly invalid frame pointer. mstart is the entry point for new
Ms, and rt0_go is the entrypoint for the program. As we try to introduce
frame pointer unwinding in more places (e.g. for heap profiling in CL
540476 or for execution trace events on the system stack in CL 593835),
we see these functions on the stack. We need to ensure that they have
valid frame pointers. These functions are both considered the "top"
(first) frame frame of the call stack, so this CL sets the frame pointer
register to 0 in these functions.
Updates #63630
Change-Id: I6a6a6964a9ebc6f68ba23d2616e5fb6f19677f97
Reviewed-on: https://go-review.googlesource.com/c/go/+/721020 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Alan Donovan [Wed, 12 Nov 2025 22:13:40 +0000 (17:13 -0500)]
go/ast: fix BasicLit.End position for raw strings containing \r
This CL causes the parser to record in a new field, BasicLit.EndPos,
the actual end position of each literal token, and to use it in
BasicLit.End. Previously, the End was computed heuristically as
Pos + len(Value). This heuristic is incorrect for a multiline
raw string literal on Windows, since the scanner normalizes
\r\n to \n.
Unfortunately the actual end position is not returned by the
Scanner.Scan method, so the scanner and parser conspire
using a global variable in the go/internal/scannerhook
package to communicate.
+ test, api change, relnote
Fixes #76031
Change-Id: I57c18a44e85f7403d470ba23d41dcdcc5a9432c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/720060 Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Filippo Valsorda [Mon, 27 Oct 2025 17:58:52 +0000 (18:58 +0100)]
crypto/mlkem: avoid a few unnecessary inverse NTT calls
We were mistakenly doing NTT⁻¹ inside the inner loop, on the components
of the inner product intead of the sum, leading to k² = 9 inverse NTT
calls instead of k = 3 inverse NTT.
Archana Ravindar [Fri, 7 Nov 2025 07:45:02 +0000 (13:15 +0530)]
runtime: hoist invariant code out of heapBitsSmallForAddrInline
The first two instructions in heapBitsSmallForAddrInline are
invariant for a given span and object and are called in
a loop within ScanObjectsSmall which figures as a hot routine
in profiles of some benchmark runs within sweet benchmark suite
(x/benchmarks/sweet), Ideally it would have been great if the
compiler hoisted this code out of the loop, Moving it out of
inner loop manually gives gains (moving it entirely out of
nested loop does not improve performance, in some cases it
even regresses it perhaps due to the early loop exit).
Tested with AMD64, ARM64, PPC64LE and S390x
Fixes #76212
Change-Id: I49c3c826b9d7bf3125ffc42c8c174cce0ecc4cbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/718680 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Anthony Knyszek [Fri, 14 Nov 2025 17:41:58 +0000 (17:41 +0000)]
runtime: usleep before stealing runnext only if not in syscall
In the scheduler's steal path, we usleep(3) before stealing a _Prunning
P's runnext slot. Before CL 646198, we would not call usleep(3) if the P
was in _Psyscall. After CL 646198, Ps with Gs in syscalls stay in
_Prunning until stolen, meaning we might unnecessarily usleep(3) where
we didn't before. This probably isn't a huge deal in most cases, but can
cause some apparent slowdowns in microbenchmarks that frequently take
the steal path while there are syscalling goroutines.
Change-Id: I5bf3df10fe61cf8d7f0e9fe9522102de66faf344
Reviewed-on: https://go-review.googlesource.com/c/go/+/720441
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
$ go get golang.org/x/tools@59ff18c
$ GOWORK=off go mod tidy
$ GOWORK=off go mod vendor
This implies golang.org/x/sys@v0.38.0, for which I have also
updated src/go.mod for consistency.
I also upgraded x/mod@3f03020 to bring in some fixes to
code that go vet would otherwise have flagged in this CL.
This brings in a number of fixes and improvements to the analysis
tools within cmd/fix, which I will apply to std and cmd presently.
For golang/go#71859
Change-Id: I56c49e7ab28eb6ba55408a3721e9a898ee3067a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/719760
Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
thepudds [Sun, 9 Nov 2025 14:24:22 +0000 (09:24 -0500)]
runtime: support runtime.freegc in size-specialized mallocs for noscan objects
This CL is part of a set of CLs that attempt to reduce how much work the
GC must do. See the design in https://go.dev/design/74299-runtime-freegc
This CL updates the smallNoScanStub stub in malloc_stubs.go to reuse
heap objects that have been freed by runtime.freegc calls, and generates
the corresponding size-specialized code in malloc_generated.go.
This CL only adds support in the specialized mallocs for noscan
heap objects (objects without pointers). A later CL handles objects
with pointers.
While we are here, we leave a couple of breadcrumbs in mkmalloc.go on
how to do the generation.
Updates #74299
Change-Id: I2657622601a27211554ee862fce057e101767a70
Reviewed-on: https://go-review.googlesource.com/c/go/+/715761 Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Alan Donovan [Fri, 14 Nov 2025 19:59:36 +0000 (14:59 -0500)]
std: fix printf("%q", int) mistakes
For #72850
Change-Id: I07e64f05c82a34b1dadb9a72e16f5045e68cbd24
Reviewed-on: https://go-review.googlesource.com/c/go/+/720642
Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
thepudds [Mon, 3 Nov 2025 21:40:40 +0000 (16:40 -0500)]
runtime: add more precise test of assist credit handling for runtime.freegc
This CL is part of a set of CLs that attempt to reduce how much work the
GC must do. See the design in https://go.dev/design/74299-runtime-freegc
This CL adds a better test of assist credit handling when heap objects
are being reused after a runtime.freegc call.
The main approach is bracketing alloc/free pairs with measurements
of the assist credit before and after, and hoping to see a net zero
change in the assist credit.
However, validating the desired behavior is perhaps a bit subtle.
To help stabilize the measurements, we do acquirem in the test code
to avoid being preempted during the measurements to reduce other code's
ability to adjust the assist credit while we are measuring, and
we also reduce GOMAXPROCS to 1.
This test currently does fail if we deliberately introduce bugs
in the runtime.freegc implementation such as if we:
- never adjust the assist credit when reusing an object, or
- always adjust the assist credit when reusing an object, or
- deliberately mishandle internal fragmentation.
The two main cases of current interest for testing runtime.freegc
are when over the course of our bracketed measurements gcBlackenEnable
is either true or false. The test attempts to exercise both of those
case by running the GC continually in the background (which we can see
seems effective based on logging and by how our deliberate bugs fail).
This passes ~10K test executions locally via stress.
A small note to the future: a previous incarnation of this test (circa
patchset 11 of this CL) did not do acquirem but had an approach of
ignoring certain measurements, which also was able to pass ~10K runs
via stress. The current version in this CL is simpler, but
recording the existence of the prior version here in case it is
useful in the future. (Hopefully not.)
Updates #74299
Change-Id: I46c7e0295d125f5884fee0cc3d3d31aedc7e5ff4
Reviewed-on: https://go-review.googlesource.com/c/go/+/717520 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Memory freed via runtime.freegc is made immediately reusable for
the next allocation in the same size class, without waiting for a
GC cycle, and hence can dramatically reduce pressure on the GC. A sample
microbenchmark included below shows strings.Builder operating roughly
2x faster.
An experimental modification to reflect to use runtime.freegc
and then using that reflect with json/v2 gave reported memory
allocation reductions of -43.7%, -32.9%, -21.9%, -22.0%, -1.0%
for the 5 official real-world unmarshalling benchmarks from
go-json-experiment/jsonbench by the authors of json/v2, covering
the CanadaGeometry through TwitterStatus datasets.
Note: there is no intent to modify the standard library to have
explicit calls to runtime.freegc, and of course such an ability
would never be exposed to end-user code.
Later CLs in this stack teach the compiler how to automatically
insert runtime.freegc calls when it can prove it is safe to do so.
(The reflect modification and other experimental changes to
the standard library were just that -- experiments. It was
very helpful while initially developing runtime.freegc to see
more complex uses and closer-to-real-world benchmark results
prior to updating the compiler.)
This CL only addresses noscan span classes (heap objects without
pointers), such as the backing memory for a []byte or string. A
follow-on CL adds support for heap objects with pointers.
If we update strings.Builder to explicitly call runtime.freegc on its
internal buf after a resize operation (but without freeing the usually
final incarnation of buf that will be returned to the user as a string),
we can see some nice benchmark results on the existing strings
benchmarks that call Builder.Write N times and then call Builder.String.
Here, the (uncommon) case of a single Builder.Write is not helped (given
it never resizes after first alloc if there is only one Write), but the
impact grows such that it is up to ~2x faster as there are more resize
operations due to more strings.Builder.Write calls:
See the design document for more discussion of the strings.Builder case.
For testing, we add tests that attempt to exercise different aspects
of the underlying freegc and mallocgc behavior on the reuse path.
Validating the assist credit manipulations turned out to be subtle,
so a test for that is added in the next CL. There are also
invariant checks added, controlled by consts (primarily the
doubleCheckReusable const currently).
This CL also adds support in runtime.freegc for GODEBUG=clobberfree=1
to immediately overwrite freed memory with 0xdeadbeef, which
can help a higher-level test fail faster in the event of a bug,
and also the GC specifically looks for that pattern and throws
a fatal error if it unexpectedly finds it.
A later CL (currently experimental) adds GODEBUG=clobberfree=2,
which uses mprotect (or VirtualProtect on Windows) to set
freed memory to fault if read or written, until the runtime
later unprotects the memory on the mallocgc reuse path.
For the cases where a normal allocation is happening without any reuse,
some initial microbenchmarks suggest the impact of these changes could
be small to negligible (at least with GOAMD64=v3):
These last benchmark results include the runtime updates to support
span classes with pointers (which was originally part of this CL,
but later split out for ease of review).
Updates #74299
Change-Id: Icceaa0f79f85c70cd1a718f9a4e7f0cf3d77803c
Reviewed-on: https://go-review.googlesource.com/c/go/+/673695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>