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>
thepudds [Wed, 5 Nov 2025 17:18:49 +0000 (12:18 -0500)]
runtime: skip tests for GOEXPERIMENT=arenas that do not handle clobberfree=1
When run with GODEBUG=clobberfree=1, three out of seven of the top-level
tests in runtime/arena_test.go fail with a SIGSEGV inside the
clobberfree function where it is overwriting freed memory
with 0xdeadbeef.
This is not a new problem. For example, this crashes in Go 1.20:
GODEBUG=clobberfree=1 go test runtime -run=TestUserArena
It would be nice for all.bash to pass with GODEBUG=clobberfree=1,
including it is useful for testing the automatic reclaiming of
dead memory via runtime.freegc in #74299.
Given the GOEXPERIMENT=arenas in #51317 is not planned to move forward
(and is hopefully slated to be replace by regions before too long),
for now we just skip those three tests in order to get all.bash
passing with GODEBUG=clobberfree=1.
Updates #74299
Change-Id: I384d96791157b30c73457d582a45dd74c5607ee0
Reviewed-on: https://go-review.googlesource.com/c/go/+/715080 Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Nicholas S. Husin [Fri, 14 Nov 2025 21:11:23 +0000 (16:11 -0500)]
net/http: do not discard body content when closing it within request handlers
(*body).Close() internally tries to discard the content of a request
body up to 256 KB. We rely on this behavior to allow connection re-use,
by calling (*body).Close() when our request handler exits.
Unfortunately, this causes an unfortunate side-effect where we would
prematurely try to discard a body content when (*body).Close() is called
from within a request handler.
There should not be a good reason for (*body).Close() to do this when
called from within a request handler. As such, this CL modifies
(*body).Close() to not discard body contents when called from within a
request handler. Note that when a request handler exits, it will still
try to discard the body content for connection re-use.
For #75933
Change-Id: I71d2431a540579184066dd35d3da49d6c85c3daf
Reviewed-on: https://go-review.googlesource.com/c/go/+/720380
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Keith Randall [Sun, 15 Jun 2025 03:10:50 +0000 (20:10 -0700)]
cmd/compile: allow multi-field structs to be stored directly in interfaces
If the struct is a bunch of 0-sized fields and one pointer field.
Merged revert-of-revert for 4 CLs.
original revert
681937 695016
693415 694996
693615 695015
694195 694995
Fixes #74092
Update #74888
Update #74908
Update #74935
(updated issues are bugs in the last attempt at this)
Change-Id: I32246d49b8bac3bb080972dc06ab432a5480d560
Reviewed-on: https://go-review.googlesource.com/c/go/+/714421
Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
Michael Anthony Knyszek [Thu, 13 Nov 2025 18:29:23 +0000 (18:29 +0000)]
runtime: put AddCleanup cleanup arguments in their own allocation
Currently, AddCleanup just creates a simple closure that calls
`cleanup(arg)` as the actual cleanup function tracked internally.
However, the argument ends up getting its own allocation. If it's tiny,
then it can also end up sharing a tiny allocation slot with the object
we're adding the cleanup to. Since the closure is a GC root, we can end
up with cleanups that never fire.
This change refactors the AddCleanup machinery to make the storage for
the argument separate and explicit. With that in place, it explicitly
allocates 16 bytes of storage for tiny arguments to side-step the tiny
allocator.
One would think this would cause an increase in memory use and more
bytes allocated, but that's actually wrong! It turns out that the
current "simple closure" actually creates _two_ closures. By making the
argument passing explicit, we eliminate one layer of closures, so this
actually results in a slightly faster AddCleanup overall and 16 bytes
less memory allocated.
This change does, however, does add 16 bytes of overhead to the cleanup
special itself, and makes each cleanup block entry 24 bytes instead of 8
bytes. This means the overall memory overhead delta with this change is
neutral, and we just have a faster cleanup. (Cleanup block entries are
transient, so I suspect any increase in memory overhead there is
negligible.)
Together with CL 719960, fixes #76007.
Change-Id: I81bf3e44339e71c016c30d80bb4ee151c8263d5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/720321 Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Anthony Knyszek [Thu, 13 Nov 2025 17:17:35 +0000 (17:17 +0000)]
runtime: add AddCleanup benchmark
Change-Id: Ia463a9b3b5980670bcf9297b4bddb60980ebfde5
Reviewed-on: https://go-review.googlesource.com/c/go/+/720320
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
Michael Anthony Knyszek [Fri, 7 Nov 2025 18:22:29 +0000 (18:22 +0000)]
runtime: ensure weak handles end up in their own allocation
Currently weak handles are atomic.Uintptr values that may end up in
a tiny block which can cause all sorts of surprising leaks. See #76007
for one example.
This change pads out the underlying allocation of the atomic.Uintptr to
16 bytes to ensure we bypass the tiny allocator, and it gets its own
block. This wastes 8 bytes per weak handle. We could potentially do
better by using the 8 byte noscan size class, but this can be a
follow-up change.
For #76007.
Change-Id: I3ab74dda9bf312ea0007f167093052de28134944
Reviewed-on: https://go-review.googlesource.com/c/go/+/719960 Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Mark Ryan [Wed, 26 Feb 2025 07:57:30 +0000 (08:57 +0100)]
doc, cmd/internal/obj/riscv: document the riscv64 assembler
Add documentation for the riscv64 assembler with a link to the
documentation from asm.html. Architecture specific assembler
documentation is provided for the other architectures but has
been missing for riscv64 until now.
Change-Id: I62ed7e6a2a4b52e0720d869e964b29e2a980223a
Reviewed-on: https://go-review.googlesource.com/c/go/+/652717 Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Auto-Submit: Joel Sing <joel@sing.id.au> Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
is incorrect as it only generates correct code if the unknown value
being compared is >= 0. If the unknown value is < 0 the rule will
incorrectly produce a constant value of 0, whereas the code optimized
away by the rule would have produced a value of 1.
A new test that causes the faulty rule to generate incorrect code
is also added to ensure that the error does not return.
Change-Id: I69224e0776596f1b9538acf9dacf9009d305f966
Reviewed-on: https://go-review.googlesource.com/c/go/+/720220 Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Joel Sing <joel@sing.id.au>
Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Aaron Chen [Thu, 13 Nov 2025 01:43:03 +0000 (01:43 +0000)]
bytes: fix panic in bytes.Buffer.Peek
This change fixed the overlooked offset in bytes.Buffer.Peek.
Otherwise, it will either return wrong result or panic with
"runtime error: slice bounds out of range".
Change-Id: Ic42fd8a27fb9703c51430f298933b91cf0d45451
GitHub-Last-Rev: fb97ebc3b188959835706626f66898d6306c16fb
GitHub-Pull-Request: golang/go#76165
Reviewed-on: https://go-review.googlesource.com/c/go/+/717640 Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Mark Freeman [Tue, 28 Oct 2025 21:54:52 +0000 (17:54 -0400)]
go/types, types2: swap object.color for Checker.objPathIdx
The type checker assigns types to objects. An object can be in
1 of 3 states, which are mapped to colors. This is stored as a
field on the object.
- white : type not known, awaiting processing
- grey : type pending, in processing
- black : type known, done processing
With the addition of Checker.objPathIdx, which maps objects to
a path index, presence in the map could signal grey coloring.
White and black coloring can be signaled by presence of
object.typ (a simple nil check).
This change removes the object.color field and its associated
methods, replacing it with an equivalent use of Checker.objPathIdx.
Checker.objPathIdx is integrated into the existing push and pop
methods, while slightly simplifying their signatures.
Note that the concept of object coloring remains the same - we
are merely changing and simplifying the mechanism which represents
the colors.
Change-Id: I91fb5e9a59dcb34c08ffc5b4ebc3f20a400094b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/715840 Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
matloob@golang.org [Tue, 11 Nov 2025 18:54:52 +0000 (13:54 -0500)]
cmd/link/internal/ld: make runtime.buildVersion with experiments valid
Specifically if there are experiments but no nonstandard toolchain
suffix such as "-devel", the go version will not be valid according to
go/version.IsValid. To fix that, always put the X: part into the suffix,
resulting in, for example, go1.25.0-X:foo.
Fixes #75953
Change-Id: I6a6a696468f3ba9b82b6a410fb88831428e93b58
Reviewed-on: https://go-review.googlesource.com/c/go/+/719701 Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Russ Cox [Thu, 13 Nov 2025 19:33:53 +0000 (14:33 -0500)]
cmd/go: fix flaky TestScript/mod_get_direct
Use our local git server instead of cloud.google.com/go,
which may go down or otherwise reject our traffic.
I built and installed git 2.23.0 and confirmed that this
updated test still fails if CL 196961 is rolled back.
So the test is still accurate at detecting the problem.
Change-Id: I58011f6cc62af2f21fbbcc526ba5401f4186eeaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/720322 Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@google.com>
Mark Freeman [Wed, 13 Aug 2025 18:55:50 +0000 (14:55 -0400)]
go/types, types2: rename definedType to declaredType and clarify docs
declaredType seems a better name for this function because it is reached
when processing a (Named or Alias) type declaration. In both cases, the
fromRHS field (rather than the underlying field) will be set.
Change-Id: Ibb1cc338e3b0632dc63f9cf2fd9d64cef6f1aaa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/695955
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
Robert Griesemer [Tue, 4 Nov 2025 00:54:43 +0000 (16:54 -0800)]
go/types, types2: check for direct cycles as a separate phase
A direct cycle is the most basic form of cycle, where no type literal or
predeclared type is reached. It is formed by a series of only TypeNames.
To illustrate, type T T is a direct cycle, but type T [1]T and type T *T
are not. Likewise, the below is also a direct cycle:
type A B
type B C
type C = A
Direct cycles are handled explicitly as part of resolveUnderlying, since
they are the only cycle which can prevent reaching an underlying type.
If we move this check to an earlier compiler phase, we can simplify
resolveUnderlying.
This is the first of (hopefully) several cycle kinds to be moved into a
preliminary phase, with the goal of simplifying the main type-checking
pass. For that reason, the bulk of the logic is placed in cycles.go.
CL based on an earlier version by Mark Freeman.
Change-Id: I3044c383278deb6acb8767c498d8cb68099ba8ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/717343
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Ian Alexander [Tue, 11 Nov 2025 18:50:51 +0000 (13:50 -0500)]
cmd/go/internal/modfetch: consolidate global vars
This commit conslidates global variables represeting the current
modfetch state into a single variable in preparation for injection via
the rsc.io/rf tool.
This commit is part of the larger effort to eliminate global module
loader state.
[git-generate]
cd src/cmd/go/internal/modfetch
rf '
add State func NewState() *State {\
s := new(State)\
s.lookupCache = new(par.Cache[lookupCacheKey, Repo])\
s.downloadCache = new(par.ErrCache[module.Version, string])\
return s\
}
add State var ModuleFetchState *State = NewState()
mv State.goSumFile State.GoSumFile
add State:/^[[:space:]]*GoSumFile /-0 // path to go.sum; set by package modload
ex {
GoSumFile -> ModuleFetchState.GoSumFile
}
mv State.workspaceGoSumFiles State.WorkspaceGoSumFiles
add State:/^[[:space:]]*WorkspaceGoSumFiles /-0 // path to module go.sums in workspace; set by package modload
ex {
WorkspaceGoSumFiles -> ModuleFetchState.WorkspaceGoSumFiles
}
add State:/^[[:space:]]*lookupCache /-0 // The Lookup cache is used cache the work done by Lookup.\
// It is important that the global functions of this package that access it do not\
// do so after they return.
add State:/^[[:space:]]*downloadCache /-0 // The downloadCache is used to cache the operation of downloading a module to disk\
// (if it'\\\''s not already downloaded) and getting the directory it was downloaded to.\
// It is important that downloadCache must not be accessed by any of the exported\
// functions of this package after they return, because it can be modified by the\
// non-thread-safe SetState function.
add State:/^[[:space:]]*downloadCache.*$/ // version → directory;
ex {
lookupCache -> ModuleFetchState.lookupCache
downloadCache -> ModuleFetchState.downloadCache
}
rm 'lookupCache'
rm 'downloadCache'
'
for dir in modload ; do
cd ../${dir}
rf '
ex {
import "cmd/go/internal/modfetch"
modfetch.GoSumFile -> modfetch.ModuleFetchState.GoSumFile
modfetch.WorkspaceGoSumFiles -> modfetch.ModuleFetchState.WorkspaceGoSumFiles
}
'
done
cd ../modfetch
rf '
rm GoSumFile
rm WorkspaceGoSumFiles
'
Change-Id: Iaa0f8a40192127457a539120eb94337940cb8d4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/719700 Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In normal use by the go command, ReadZip always happens after Stat,
which makes sure that the relevant revision has been fetched to
local disk. But TestReadZip calls ReadZip directly, and ReadZip was not
ensuring that fetch had happened.
This made 'go test' pass (because other earlier tests had done Stat of
the hg test repo) but 'go test -run=ReadZip' fail by itself.
And on big enough machines, the tests that were doing the Stat
were running in parallel with ReadZip, causing non-deterministic
failures depending on whether the Stat completed before ReadZip started.
Fix the race by calling Stat directly in ReadZip, like we already do in ReadFile.
Fixes longtest builder flake.
Change-Id: Ib42f64876b7ef51d8148c616539b412b42f8b24e
Reviewed-on: https://go-review.googlesource.com/c/go/+/720280 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Pratt [Fri, 24 Oct 2025 19:14:59 +0000 (15:14 -0400)]
runtime: prefer to restart Ps on the same M after STW
Today, Ps jump around arbitrarily across STW. Instead, try to keep the P
on the previous M it ran on. In the future, we'll likely want to try to
expand this beyond STW to create a more general affinity for specific
Ms.
For this to be useful, the Ps need to have runnable Gs. Today, STW
preemption goes through goschedImpl, which places the G on the global
run queue. If that was the only G then the P won't have runnable
goroutines anymore.
It makes more sense to keep the G with its P across STW anyway, so add a
special case to goschedImpl for that.
On my machine, this CL reduces the error rate in TestTraceSTW from 99.8%
to 1.9%.
As a nearly 2% error rate shows, there are still cases where this best
effort scheduling doesn't work. The most obvious is that while
procresize assigns Ps back to their original M, startTheWorldWithSema
calls wakep to start a spinning M. The spinning M may steal a goroutine
from another P if that P is too slow to start.
For #65694.
Change-Id: I6a6a636c0969c587d039b68bc68ea16c74ff1fc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/714801 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>
Michael Anthony Knyszek [Thu, 13 Nov 2025 00:09:05 +0000 (00:09 +0000)]
runtime/pprof: fix goroutine leak profile tests for noopt
The goroutine leak profile tests currently rely on a function being
inlined, which results in a slightly different representation in the
pprof proto. This function is not inlined on the noopt builder.
Disable inlining of the one function which could be inlined to align but
the regular and noopt builder versions of this test. We're not
interested in testing the inlining functionality of profiles with this
test, we care about certain stack frames appearing in a certain order.
This also simplifies a bunch of the checking in the test.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-noopt
Change-Id: I28902cc4c9fae32d1e3fa41b93b00c3be4d6074a
Reviewed-on: https://go-review.googlesource.com/c/go/+/720100 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Robert Griesemer [Mon, 13 Oct 2025 23:57:34 +0000 (16:57 -0700)]
spec: remove cycle restriction for type parameters
Fixes #75883.
Change-Id: I708c0594ef3182d3aca37a6358aa0a0ef89809b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/711422 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Joel Sing [Tue, 9 Sep 2025 14:17:00 +0000 (00:17 +1000)]
cmd/asm,cmd/internal/obj/riscv: add support for riscv compressed instructions
Add support for compressed instructions in the RISC-V assembler. This
implements instruction validation and encoding for all instructions in
the "C" extension.
It is worth noting that the validation and encoding of these instructions
is far more convoluted then the typical instruction validation and
encoding. While the current model has been followed for now, it would be
worth revisiting this in the future and potentially switching to a table
based or even per-instruction implementation.
Additionally, the current instruction encoding is lacking some of the bits
needed for compressed instructions - this is solved by compressedEncoding,
which provides the missing information. This will also be addressed in the
future, likely by changing the instruction encoding format.
Updates #71105
Change-Id: I0f9359d63f93ebbdc6e708e79429b2d61eae220d
Reviewed-on: https://go-review.googlesource.com/c/go/+/713020 Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Joel Sing [Tue, 9 Sep 2025 15:16:00 +0000 (01:16 +1000)]
cmd/internal/obj/riscv: implement better bit pattern encoding
Replace the extractBitAndShift function with an encodeBitPattern function.
This allows the caller to specify a slice of bits that are to be extracted
and encoded, rather than making multiple function calls and combining the
results.
Change-Id: I3d51caa10ecf714f2ad2fb66d38376202c4e0628
Reviewed-on: https://go-review.googlesource.com/c/go/+/702397 Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Michael Anthony Knyszek [Wed, 12 Nov 2025 18:22:58 +0000 (18:22 +0000)]
cmd/go: keep objects alive while stopping cleanups
There are two places in cmd/go where cleanups are stopped before they
fire, and where the objects the cleanups are attached to may be dead
while we call Stop. This is essentially a race between Stop and the
cleanup being called. This can be fine, but these cleanups are used as
a way to check some invariants, so just panic if they're executed. As a
result, if they fire erroneously, they'll take down the whole process,
even if no invariant was actually violated.
The runtime.Cleanup.Stop documentation explains that users of Stop need
to hold the object alive across the call to Stop if they want to be sure
that Stop succeeds, so do that here by adding an explicit
runtime.KeepAlive call.
Kudos to Michael Pratt for finding the issue.
Fixes #74780.
Change-Id: I22e6f4642ac68f727ca3781f5d39a85015047925
Reviewed-on: https://go-review.googlesource.com/c/go/+/719961
Auto-Submit: 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> Reviewed-by: Carlos Amedee <carlos@golang.org>
Michael Pratt [Wed, 12 Nov 2025 20:20:54 +0000 (15:20 -0500)]
runtime: fix list test memory management for mayMoreStack
The NIH tests simply failed to allocate the nodes outside the heap at
all. The Manual tests failed to keep the nodes alive, allowing the GC to
collect them.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a636c434bb703d6888383d32dbf95fb0a15ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/719962
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I6fceb99b2dc8682685dca2e4289fcd58e2e5a0e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/718340
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Sean Liao [Sat, 18 Oct 2025 09:31:12 +0000 (10:31 +0100)]
net/url: disallow raw IPv6 addresses in host
RFC 3986 requires square brackets around IPv6 addresses.
Parse's acceptance of raw IPv6 addresses is non compliant,
and complicates splitting out a port.
This is a resubmission of CL 710176 after the revert in CL 711800,
this time with a new urlstrictipv6 godebug to control the behavior.
Fixes #31024
Fixes #75223
Change-Id: I4cbe5bb84266b3efe9c98cf4300421ddf1df7291
Reviewed-on: https://go-review.googlesource.com/c/go/+/712840 Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Daniel Morsing [Wed, 5 Nov 2025 18:33:44 +0000 (18:33 +0000)]
cmd/compile: optimize liveness in stackalloc
The stackalloc code needs to run a liveness pass to build the
interference graph between stack slots. Because the values that we need
liveness over is so sparse, we can optimize the analysis by using a path
exploration algorithm rather than a iterative dataflow one
In local testing, this cuts 74.05 ms of CPU time off a build of cmd/compile.
Change-Id: I765ace87d5e8aae177e65eb63da482e3d698bea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/718540 Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
Roland Shoemaker [Sun, 9 Nov 2025 19:50:42 +0000 (11:50 -0800)]
crypto/x509: move BetterTLS suite from crypto/tls
Move the BetterTLS test suite from crypto/tls to crypto/x509. Despite
the name, the test suites we care about are actually related to X.509
path building and name constraint checking. As such it makes more sense
to include these in the crypto/x509 package, so we are more likely to
catch breaking behaviors during local testing.
Change-Id: I5237903dcc9d9f60d6c7070db3c996ceb643b04c
Reviewed-on: https://go-review.googlesource.com/c/go/+/719120
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Vlad Saioc [Thu, 6 Nov 2025 09:53:28 +0000 (09:53 +0000)]
runtime,runtime/pprof: clean up goroutine leak profile writing
Cleaned up goroutine leak profile extraction:
- removed the acquisition of goroutineProfile semaphore
- inlined the call to saveg when recording stacks instead of using
doRecordGoroutineProfile, which had side-effects over
goroutineProfile fields.
Added regression tests for goroutine leak profiling frontend for binary
and debug=1 profile formats.
Added stress tests for concurrent goroutine and goroutine leak profile requests.
Change-Id: I55c1bcef11e9a7fb7699b4c5a2353e594d3e7173
GitHub-Last-Rev: 5e9eb3b1d80c4d2d9b668a01f6b39a7b42f7bb45
GitHub-Pull-Request: golang/go#76045
Reviewed-on: https://go-review.googlesource.com/c/go/+/714580 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> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Sean Liao [Sun, 5 Oct 2025 18:21:59 +0000 (19:21 +0100)]
cmd/go: clarify the -o testflag is only for copying the binary
Fixes #74769
Change-Id: Iebbaea8fb1a25e30a541a827815def9e269a8135
Reviewed-on: https://go-review.googlesource.com/c/go/+/709255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Ian Alexander <jitsu@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
Sean Liao [Tue, 11 Nov 2025 21:08:26 +0000 (21:08 +0000)]
os/exec: include Cmd.Start in the list of methods that run Cmd
Fixes #76265
Change-Id: I451271c5662dd3bcdeec07b55761b15f64c00dcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/719860 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
Alan Donovan [Tue, 11 Nov 2025 19:48:22 +0000 (14:48 -0500)]
std,cmd: go fix -any std cmd
This change mechanically replaces all occurrences of interface{}
by 'any' (where deemed safe by the 'any' modernizer) throughout
std and cmd, minus their vendor trees.
Since this fix is relatively numerous, it gets its own CL.
Also, 'go generate go/types'.
Change-Id: I14a6b52856c3291c1d27935409bca8d5fd4242a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/719702
Commit-Queue: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
Michael Pratt [Fri, 24 Oct 2025 18:54:21 +0000 (14:54 -0400)]
runtime: doubly-linked sched.midle list
This will be used by CL 714801 to remove Ms from the middle of the list.
We could simply convert schedlink to the doubly-linked list, bringing
along all other uses of schedlink.
However, CL 714801 removes Ms from the middle of the midle list. It
would be an easy mistake to make to accidentally remove an M from
schedlink, assuming that it is on the midle list when it is actually on
a completely different list. Using separate a list node makes this
impossible.
For #65694.
Change-Id: I6a6a636c223d925fdc30c0c648460cbf5c2af4d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/714800 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>
Michael Pratt [Tue, 21 Oct 2025 19:49:36 +0000 (15:49 -0400)]
runtime: reusable intrusive doubly-linked list
Unfortunately we have two nearly identical types. One for standard types
and one for sys.NotInHeap types or cases that must avoid write barriers.
The latter must use uintptr fields, as assignment to unsafe.Pointer
fields generates a write barrier.
Change-Id: I6a6a636c62d83fa93b991033c7108d3b934412ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/714020 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Commit-Queue: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Russ Cox [Thu, 6 Nov 2025 18:55:25 +0000 (13:55 -0500)]
cmd/go: implement accurate pseudo-versions for Mercurial
This is CL 124515 (which only did Git) but for Mercurial,
quite a few years late. I'm not sure why we didn't do it
at the time - probably Mercurial blindness. Do it now.
Change-Id: I28f448a19143f7ce3de337cd1891bae86023b499
Reviewed-on: https://go-review.googlesource.com/c/go/+/718502 Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>