aboutsummaryrefslogtreecommitdiff
path: root/src/runtime
AgeCommit message (Collapse)Author
2025-04-24runtime, internal/fuzz: add comparison tracing for libFuzzer on loong64limeidan
Change-Id: I212330962453139fa353db29928786b64c9ff063 Reviewed-on: https://go-review.googlesource.com/c/go/+/667455 Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-04-24runtime: fix typo in commentchangwang ma
Change-Id: I85f518e36c18f4f0eda8b167750b43cd8c48ecff Reviewed-on: https://go-review.googlesource.com/c/go/+/622675 Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Austin Clements <austin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-04-24runtime/debug: update SetCrashOutput example to not pass parent env varsFelix Geisendörfer
Fixes #73490 Change-Id: I500fa73f4215c7f490779f53c1c2c0d775f51a95 Reviewed-on: https://go-review.googlesource.com/c/go/+/667775 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-04-24runtime: fix tag pointers on aixKeith Randall
Clean up tagged pointers a bit. I got the shifts wrong for the weird aix case. Change-Id: I21449fd5973f4651fd1103d3b8be9c2b9b93a490 Reviewed-on: https://go-review.googlesource.com/c/go/+/667715 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-04-23runtime: use precise bounds of Go data/bss for race detectorKeith Randall
We only want to call into the race detector for Go global variables. By rounding up the region bounds, we can include some C globals. Even worse, we can include only *part* of a C global, leading to race{read,write}range calls which straddle the end of shadow memory. That causes the race detector to barf. Fix some off-by-one errors in the assembly comparisons. We want to skip calling the race detector when addr == racedataend. Fixes #73483 Change-Id: I436b0f588d6165b61f30cb7653016ba9b7cbf585 Reviewed-on: https://go-review.googlesource.com/c/go/+/667655 Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2025-04-23runtime: align taggable pointers more so we can use low bits for tagKeith Randall
Currently we assume alignment to 8 bytes, so we can steal the low 3 bits. This CL assumes alignment to 512 bytes, so we can steal the low 9 bits. That's 6 extra bits! Aligning to 512 bytes wastes a bit of space but it is not egregious. Most of the objects that we make tagged pointers to are pretty big. Update #49405 Change-Id: I66fc7784ac1be5f12f285de1d7851d5a6871fb75 Reviewed-on: https://go-review.googlesource.com/c/go/+/665815 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-04-23runtime: move some malloc constants to internal/runtime/gcMichael Anthony Knyszek
These constants are needed by some future generator programs. Change-Id: I5dccd009cbb3b2f321523bc0d8eaeb4c82e5df81 Reviewed-on: https://go-review.googlesource.com/c/go/+/655276 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>
2025-04-23runtime: move sizeclass defs to new package internal/runtime/gcMichael Anthony Knyszek
We will want to reference these definitions from new generator programs, and this is a good opportunity to cleanup all these old C-style names. Change-Id: Ifb06f0afc381e2697e7877f038eca786610c96de Reviewed-on: https://go-review.googlesource.com/c/go/+/655275 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-04-22runtime: fix typos in commentsXiaolin Zhao
Change-Id: Id169b68cc93bb6eb4cdca384efaaf971fcfa32b7 Reviewed-on: https://go-review.googlesource.com/c/go/+/666316 Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-04-22Revert "runtime: only poll network from one P at a time in findRunnable"Carlos Amedee
This reverts commit 352dd2d932c1c1c6dbc3e112fcdfface07d4fffb. Reason for revert: cockroachdb benchmark failing. Likely due to CL 564197. For #73474 Change-Id: Id5d83cd8bb8fe9ee7fddb8dc01f1a01f2d40154e Reviewed-on: https://go-review.googlesource.com/c/go/+/667336 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> Auto-Submit: Carlos Amedee <carlos@golang.org>
2025-04-22runtime, internal/runtime/maps: speed-up empty/zero map lookupsMateusz Poliwczak
This lets the inliner do a better job optimizing the mapKeyError call. goos: linux goarch: amd64 pkg: runtime cpu: AMD Ryzen 5 4600G with Radeon Graphics │ /tmp/before2 │ /tmp/after3 │ │ sec/op │ sec/op vs base │ MapAccessZero/Key=int64-12 1.875n ± 0% 1.875n ± 0% ~ (p=0.506 n=25) MapAccessZero/Key=int32-12 1.875n ± 0% 1.875n ± 0% ~ (p=0.082 n=25) MapAccessZero/Key=string-12 1.902n ± 1% 1.902n ± 1% ~ (p=0.256 n=25) MapAccessZero/Key=mediumType-12 2.816n ± 0% 1.958n ± 0% -30.47% (p=0.000 n=25) MapAccessZero/Key=bigType-12 2.815n ± 0% 1.935n ± 0% -31.26% (p=0.000 n=25) MapAccessEmpty/Key=int64-12 1.942n ± 0% 2.109n ± 0% +8.60% (p=0.000 n=25) MapAccessEmpty/Key=int32-12 2.110n ± 0% 1.940n ± 0% -8.06% (p=0.000 n=25) MapAccessEmpty/Key=string-12 2.024n ± 0% 2.109n ± 0% +4.20% (p=0.000 n=25) MapAccessEmpty/Key=mediumType-12 3.157n ± 0% 2.344n ± 0% -25.75% (p=0.000 n=25) MapAccessEmpty/Key=bigType-12 3.054n ± 0% 2.115n ± 0% -30.75% (p=0.000 n=25) geomean 2.305n 2.011n -12.75% Change-Id: Iee83930884dc4c8a791a711aa189a1c93b68d536 Reviewed-on: https://go-review.googlesource.com/c/go/+/663495 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-04-22runtime: commit to spinbitmutex GOEXPERIMENTRhys Hiltner
Use the "spinbit" mutex implementation always (including on platforms that need to emulate atomic.Xchg8), and delete the prior "tristate" implementations. The exception is GOARCH=wasm, where the Go runtime does not use multiple threads. For #68578 Change-Id: Ifc29bbfa05071d776c23a19ae185891a03a82417 Reviewed-on: https://go-review.googlesource.com/c/go/+/658456 Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-04-22runtime: fix test of when a mutex is contendedRhys Hiltner
This is used only in tests that verify reports of runtime-internal mutex contention. For #66999 For #70602 Change-Id: I72cb1302d8ea0524f1182ec892f5c9a1923cddba Reviewed-on: https://go-review.googlesource.com/c/go/+/667095 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
2025-04-22runtime: only poll network from one P at a time in findRunnableIan Lance Taylor
For #65064 Change-Id: Ifecd7e332d2cf251750752743befeda4ed396f33 Reviewed-on: https://go-review.googlesource.com/c/go/+/564197 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Artur M. Wolff <artur.m.wolff@gmail.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-04-18internal,runtime: use the builtin clearapocelipes
To simplify the code. Change-Id: I023de705504c0b580718eec3c7c563b6cf2c8184 GitHub-Last-Rev: 026b32c799b13d0c7ded54f2e61429e6c5ed0aa8 GitHub-Pull-Request: golang/go#73412 Reviewed-on: https://go-review.googlesource.com/c/go/+/666118 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> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-04-15runtime: don't use cgo_unsafe_args for syscall9 wrapperKeith Randall
It uses less stack space this way. Similar to CL 386719 Update #71302 Change-Id: I585bde5f681a90a6900cbd326994ab8a122fd148 Reviewed-on: https://go-review.googlesource.com/c/go/+/665695 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-04-15runtime: fix 9-arg syscall on darwin/amd64Keith Randall
The last 3 arguments need to be passed on the stack, not registers. Fixes #71302 Change-Id: Ib1155ad1a805957fad3d9594c93981a558755591 Reviewed-on: https://go-review.googlesource.com/c/go/+/665435 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
2025-04-15runtime: size field for gQueue and gListDmitrii Martynov
Before CL, all instances of gQueue and gList stored the size of structures in a separate variable. The size changed manually and passed as a separate argument to different functions. This CL added an additional field to gQueue and gList structures to store the size. Also, the calculation of size was moved into the implementation of API for these structures. This allows to reduce possible errors by eliminating manual calculation of the size and simplifying functions' signatures. Change-Id: I087da2dfaec4925e4254ad40fce5ccb4c175ec41 Reviewed-on: https://go-review.googlesource.com/c/go/+/664777 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org>
2025-04-13runtime: optimize the function memmove using SIMD on loong64Guoqi Chen
goos: linux goarch: loong64 pkg: runtime cpu: Loongson-3A6000 @ 2500.00MHz | bench.old | bench.new | | sec/op | sec/op vs base | Memmove/256 10.215n ± 0% 6.407n ± 0% -37.28% (p=0.000 n=10) Memmove/512 16.940n ± 0% 8.694n ± 0% -48.68% (p=0.000 n=10) Memmove/1024 29.64n ± 0% 15.22n ± 0% -48.65% (p=0.000 n=10) Memmove/2048 55.42n ± 0% 28.03n ± 0% -49.43% (p=0.000 n=10) Memmove/4096 106.55n ± 0% 53.65n ± 0% -49.65% (p=0.000 n=10) MemmoveOverlap/256 11.01n ± 0% 10.84n ± 0% -1.54% (p=0.000 n=10) MemmoveOverlap/512 17.41n ± 0% 15.09n ± 0% -13.35% (p=0.000 n=10) MemmoveOverlap/1024 30.23n ± 0% 28.70n ± 0% -5.08% (p=0.000 n=10) MemmoveOverlap/2048 55.87n ± 0% 42.84n ± 0% -23.32% (p=0.000 n=10) MemmoveOverlap/4096 107.10n ± 0% 87.90n ± 0% -17.93% (p=0.000 n=10) MemmoveUnalignedDst/256 16.665n ± 1% 9.611n ± 0% -42.33% (p=0.000 n=10) MemmoveUnalignedDst/512 24.75n ± 0% 11.81n ± 0% -52.29% (p=0.000 n=10) MemmoveUnalignedDst/1024 43.25n ± 0% 20.46n ± 1% -52.68% (p=0.000 n=10) MemmoveUnalignedDst/2048 75.68n ± 0% 39.64n ± 0% -47.61% (p=0.000 n=10) MemmoveUnalignedDst/4096 152.75n ± 0% 80.08n ± 0% -47.57% (p=0.000 n=10) MemmoveUnalignedDstOverlap/256 11.88n ± 1% 10.95n ± 0% -7.83% (p=0.000 n=10) MemmoveUnalignedDstOverlap/512 19.71n ± 0% 16.20n ± 0% -17.83% (p=0.000 n=10) MemmoveUnalignedDstOverlap/1024 39.84n ± 0% 28.74n ± 0% -27.86% (p=0.000 n=10) MemmoveUnalignedDstOverlap/2048 81.12n ± 0% 40.11n ± 0% -50.56% (p=0.000 n=10) MemmoveUnalignedDstOverlap/4096 166.20n ± 0% 85.11n ± 0% -48.79% (p=0.000 n=10) MemmoveUnalignedSrc/256 10.945n ± 1% 6.807n ± 0% -37.81% (p=0.000 n=10) MemmoveUnalignedSrc/512 19.33n ± 4% 11.01n ± 1% -43.02% (p=0.000 n=10) MemmoveUnalignedSrc/1024 34.74n ± 0% 19.69n ± 0% -43.32% (p=0.000 n=10) MemmoveUnalignedSrc/2048 65.98n ± 0% 39.79n ± 0% -39.69% (p=0.000 n=10) MemmoveUnalignedSrc/4096 126.00n ± 0% 81.31n ± 0% -35.47% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_256_0 13.610n ± 0% 7.608n ± 0% -44.10% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_256_0 12.81n ± 0% 10.94n ± 0% -14.60% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_256_1 17.17n ± 0% 10.01n ± 0% -41.70% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_256_1 17.62n ± 0% 11.21n ± 0% -36.38% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_256_4 16.22n ± 0% 10.01n ± 0% -38.29% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_256_4 16.42n ± 0% 11.21n ± 0% -31.73% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_256_7 14.09n ± 0% 10.79n ± 0% -23.39% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_256_7 14.82n ± 0% 11.21n ± 0% -24.36% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_4096_0 109.80n ± 0% 75.07n ± 0% -31.63% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_4096_0 108.90n ± 0% 78.48n ± 0% -27.93% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_4096_1 113.60n ± 0% 78.88n ± 0% -30.56% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_4096_1 113.80n ± 0% 80.56n ± 0% -29.20% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_4096_4 112.30n ± 0% 80.35n ± 0% -28.45% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_4096_4 113.80n ± 1% 80.58n ± 0% -29.19% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_4096_7 110.70n ± 0% 79.68n ± 0% -28.02% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_4096_7 111.10n ± 0% 80.58n ± 0% -27.47% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_65536_0 4.669µ ± 0% 2.680µ ± 0% -42.60% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_65536_0 5.083µ ± 0% 2.672µ ± 0% -47.43% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_65536_1 4.716µ ± 0% 2.677µ ± 0% -43.24% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_65536_1 4.611µ ± 0% 2.672µ ± 0% -42.05% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_65536_4 4.718µ ± 0% 2.678µ ± 0% -43.24% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_65536_4 4.610µ ± 0% 2.673µ ± 0% -42.01% (p=0.000 n=10) MemmoveUnalignedSrcDst/f_65536_7 4.724µ ± 0% 2.678µ ± 0% -43.31% (p=0.000 n=10) MemmoveUnalignedSrcDst/b_65536_7 4.611µ ± 0% 2.673µ ± 0% -42.03% (p=0.000 n=10) MemmoveUnalignedSrcOverlap/256 13.62n ± 0% 11.97n ± 0% -12.11% (p=0.000 n=10) MemmoveUnalignedSrcOverlap/512 23.96n ± 0% 16.20n ± 0% -32.39% (p=0.000 n=10) MemmoveUnalignedSrcOverlap/1024 43.95n ± 0% 30.25n ± 0% -31.18% (p=0.000 n=10) MemmoveUnalignedSrcOverlap/2048 84.29n ± 0% 42.27n ± 0% -49.85% (p=0.000 n=10) MemmoveUnalignedSrcOverlap/4096 170.50n ± 0% 85.47n ± 0% -49.87% (p=0.000 n=10) Change-Id: Id1c3fbfed049d9a665f05f7c1af84e9fbd45fddf Reviewed-on: https://go-review.googlesource.com/c/go/+/663395 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Meidan Li <limeidan@loongson.cn>
2025-04-11all: use built-in min, max functionsMarcel Meyer
Change-Id: Ie76ebb556d635068342747f3f91dd7dc423df531 GitHub-Last-Rev: aea61fb3a054e6bd24f4684f90fb353d5682cd0b GitHub-Pull-Request: golang/go#73340 Reviewed-on: https://go-review.googlesource.com/c/go/+/664677 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2025-04-11runtime: handle m0 padding betterRuss Cox
The SpinbitMutex experiment requires m structs other than m0 to be allocated in 2048-byte size class, by adding padding. Do the calculation more explicitly, to avoid future CLs like CL 653335. Change-Id: I83ae1e86ef3711ab65441f4e487f94b9e1429029 Reviewed-on: https://go-review.googlesource.com/c/go/+/654595 Reviewed-by: Rhys Hiltner <rhys.hiltner@gmail.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-04-11runtime: use built-in min functionMarcel Meyer
Change-Id: I625c392864c97cefc2ac8f23612e3f62f7fbba23 GitHub-Last-Rev: 779f756850e7bf0cf2059ed0b4d412638c872f7e GitHub-Pull-Request: golang/go#73313 Reviewed-on: https://go-review.googlesource.com/c/go/+/664016 Reviewed-by: Keith Randall <khr@golang.org> 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> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-04-09runtime: explicitly exclude a potential deadlock in the schedulerDmitrii Martynov
The following sequence in the scheduler may potentially lead to deadlock: - globrunqget() -> runqput() -> runqputslow() -> globrunqputbatch() However, according to the current logic of the scheduler it is not possible to face the deadlock. The patch explicitly excludes the deadlock, even though it is impossible situation at the moment. Additionally, the "runq" and "globrunq" APIs were partially refactored, which allowed to minimize the usage of these APIs by each other. This will prevent situations described in the CL. Change-Id: I7318f935d285b95522998e0903eaa6193af2ba48 Reviewed-on: https://go-review.googlesource.com/c/go/+/662216 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> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-04-08runtime: use internal/byteorderapocelipes
To simplify the code. Change-Id: Ib1af5009cc25bb29fd26fdb7b29ff4579f0150aa GitHub-Last-Rev: f698a8a771ac8c6ecb745ea4c27a7c677c1789d1 GitHub-Pull-Request: golang/go#73255 Reviewed-on: https://go-review.googlesource.com/c/go/+/663735 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-04-07runtime: protect plan9 time_now function with !faketime build tagRichard Miller
The introduction of monotonic time support for Plan 9 in CL 656755 causes a build error with multiple declaration of time_now when built with tag faketime. Correct this by moving function time_now into its own source file with !faketime build tag. Fixes #73169 Change-Id: Id7a9a1c77e286511e25546089681f2f88a9538bb Reviewed-on: https://go-review.googlesource.com/c/go/+/662856 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: David du Colombier <0intro@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-04-06all: use slices.Equal to simplify codecuishuang
Change-Id: Ib3be7cee6ca6dce899805aac176ca789eb2fd0f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/661738 Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Sean Liao <sean@liao.dev> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-04-04internal/syscall/windows: use unsafe.Pointer instead of uintptrqmuntal
Some functions accept a uintptr when they should accept an unsafe.Pointer, else the compiler won't know that the pointer should be kept alive across the call, potentially causing undefined behavior. Fixes #73156 (potentially) Change-Id: I29c847eb8ffbb785fabf217e9f3718d10cfb5047 Reviewed-on: https://go-review.googlesource.com/c/go/+/662855 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2025-04-04cmd/compile: stack allocate variable-sized makesliceKeith Randall
Instead of always allocating variable-sized "make" calls on the heap, allocate a small, constant-sized array on the stack and use that array as the backing store if it is big enough. Requires the result of the "make" doesn't escape. if cap <= K { var arr [K]E slice = arr[:len:cap] } else { slice = makeslice(E, len, cap) } Pretty conservatively for now, K = 32/sizeof(E). The slice header is already 24 bytes, so wasting 32 bytes of stack if the requested size is too big isn't that bad. Larger would waste more stack space but maybe avoid more allocations. This CL also requires the element type be pointer-free. Maybe we could relax that at some point, but it is hard. If the element type has pointers we can get heap->stack pointers (in the case where the requested size is too big and the slice is heap allocated). Note that this only handles the case of makeslice called directly from compiler-generated code. It does not handle slices built in the runtime on behalf of the program (e.g. in growslice). Some of those are currently handled by passing in a tmpBuf (e.g. concatstrings), but we could probably do more. Change-Id: I8378efad527cd00d25948a80b82a68d88fbd93a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/653856 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-04-04runtime: add thread exit plus vgetrandom stress testMichael Pratt
Add a regression test similar to the reproducer from #73141 to try to help catch future issues with vgetrandom and thread exit. Though the test isn't very precise, it just hammers thread exit. When the test reproduces #73141, it simply crashes with a SIGSEGV and no output or stack trace, which would be very unfortunate on a builder. https://go.dev/issue/49165 tracks collecting core dumps from builders, which would make this more tractable to debug. For #73141. Change-Id: I6a6a636c7d7b41e2729ff6ceb30fd7f979aa9978 Reviewed-on: https://go-review.googlesource.com/c/go/+/662636 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2025-04-03runtime: cleanup M vgetrandom state before dropping PMichael Pratt
When an M is destroyed, we put its vgetrandom state back on the shared list for another M to reuse. This list is simply a slice, so appending to the slice may allocate. Currently this operation is performed in mdestroy, after the P is released, meaning allocation is not allowed. More the cleanup earlier in mdestroy when allocation is still OK. Also add //go:nowritebarrierrec to mdestroy since it runs without a P, which would have caught this bug. Fixes #73141. Change-Id: I6a6a636c3fbf5c6eec09d07a260e39dbb4d2db12 Reviewed-on: https://go-review.googlesource.com/c/go/+/662455 Reviewed-by: Jason Donenfeld <Jason@zx2c4.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2025-04-02runtime: simplify needzero logickhr@golang.org
We always need to zero allocations with pointers in them. So we don't need some of the mallocs to take a needzero argument. Change-Id: Ideaa7b738873ba6a93addb5169791b42e2baad7c Reviewed-on: https://go-review.googlesource.com/c/go/+/660455 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-03-31runtime: fix plan9 monotonic time, crypto randomnessRuss Cox
Open /dev/bintime at process start on Plan 9, marked close-on-exec, hold it open for the duration of the process, and use it for obtaining time. The change to using /dev/bintime also sets up for an upcoming Plan 9 change to add monotonic time to that file. If the monotonic field is available, then nanotime1 and time.now use that field. Otherwise they fall back to using Unix nanoseconds as "monotonic", as they always have. Before this CL, monotonic time went backward any time aux/timesync decided to adjust the system's time-of-day backward. Also use /dev/random for randomness (once at startup). Before this CL, there was no real randomness in the runtime on Plan 9 (the crypto/rand package still had some). Now there will be. Change-Id: I0c20ae79d3d96eff1a5f839a56cec5c4bc517e61 Reviewed-on: https://go-review.googlesource.com/c/go/+/656755 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Bypass: Russ Cox <rsc@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-03-30internal/runtime/maps: speed up small map lookups ~1.7x for unpredictable keysthepudds
On master, lookups on small Swiss Table maps (<= 8 elements) for non-specialized key types are seemingly a performance regression compared to the Go 1.23 map implementation (reported in #70849). Currently, a linear scan is used for gets in these cases. This CL changes (*Map).getWithKeySmall to instead use the SIMD or SWAR match on the control bytes to then jump to candidate matching slots, with sample results below for a 16-byte key. This especially helps the hit case when the key is unpredictable, which previously had to scan an unpredictable number of control bytes to find a candidate slot when the key is unpredictable. Separately, other CLs in this stack modify the main Swiss Table benchmarks to randomize lookup key order (vs. previously most of the benchmarks had a repeating lookup key ordering, which likely is predictable until the map is too big). We have sample results for the randomized key order benchmarks followed by results from the older benchmarks. The first table below is with randomized key order. For hits, the older results get slower as there are more elements. With this CL, we see hits for unpredictable key ordering (sizes 2-8) get a ~1.7x speedup from ~25ns to ~14ns, with a now consistent lookup time for the different sizes. (The 1 element size map has a predictable key ordering because there is only one key, and that reports a modest ~0.5ns or ~3% performance penalty). Misses for unpredictable key order get a ~1.3x speedup, from ~13ns to ~10ns, with similar results for the 1 element size. │ no-fix-new-bmarks │ fix-with-new-bmarks │ │ sec/op │ sec/op vs base │ MapSmallAccessHit/Key=smallType/Elem=int32/len=1-4 13.26n ± 0% 13.64n ± 0% +2.90% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=2-4 19.47n ± 0% 13.62n ± 0% -30.05% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=3-4 22.23n ± 0% 13.64n ± 0% -38.68% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=4-4 23.98n ± 0% 13.64n ± 0% -43.11% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=5-4 25.02n ± 0% 13.67n ± 0% -45.35% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=6-4 25.77n ± 1% 13.68n ± 2% -46.89% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=7-4 26.38n ± 0% 13.64n ± 0% -48.28% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=8-4 26.31n ± 0% 13.71n ± 21% -47.90% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=1-4 13.055n ± 0% 9.815n ± 0% -24.82% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=2-4 13.070n ± 0% 9.813n ± 0% -24.92% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=3-4 13.060n ± 0% 9.819n ± 0% -24.82% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=4-4 13.075n ± 0% 9.816n ± 0% -24.92% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=5-4 13.060n ± 0% 9.826n ± 0% -24.76% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=6-4 13.095n ± 19% 9.834n ± 31% -24.90% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=7-4 13.075n ± 19% 9.822n ± 27% -24.88% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=8-4 13.11n ± 16% 12.14n ± 19% -7.43% (p=0.000 n=20) The next table uses the original benchmarks from just before this CL stack (i.e., without shuffling lookup keys). With this CL, we see improvement that is directionally similar to the above results but not as large, presumably because the branches in the linear scan are fairly predictable with predictable keys. (The numbers here also include the time from a mod in the benchmark code, which seemed to take around ~1/3 of CPU time based on spot checking a couple of examples, vs. the modified benchmarks shown above have removed that mod). │ master-8c3e391573 │ just-fix-with-old-bmarks │ │ sec/op │ sec/op vs base │ MapSmallAccessHit/Key=smallType/Elem=int32/len=1-4 20.85n ± 0% 21.69n ± 0% +4.03% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=2-4 21.22n ± 0% 21.70n ± 0% +2.24% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=3-4 21.73n ± 0% 21.71n ± 0% ~ (p=0.158 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=4-4 22.06n ± 0% 21.71n ± 0% -1.56% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=5-4 22.41n ± 0% 21.73n ± 0% -3.01% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=6-4 22.71n ± 0% 21.72n ± 0% -4.38% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=7-4 22.98n ± 0% 21.71n ± 0% -5.53% (p=0.000 n=20) MapSmallAccessHit/Key=smallType/Elem=int32/len=8-4 23.20n ± 0% 21.72n ± 0% -6.36% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=1-4 19.95n ± 0% 17.30n ± 0% -13.28% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=2-4 19.96n ± 0% 17.31n ± 0% -13.28% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=3-4 19.95n ± 0% 17.29n ± 0% -13.33% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=4-4 19.95n ± 0% 17.30n ± 0% -13.29% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=5-4 19.96n ± 25% 17.32n ± 0% -13.22% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=6-4 19.99n ± 24% 17.29n ± 0% -13.51% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=7-4 19.97n ± 20% 17.34n ± 16% -13.14% (p=0.000 n=20) MapSmallAccessMiss/Key=smallType/Elem=int32/len=8-4 20.02n ± 11% 17.33n ± 14% -13.44% (p=0.000 n=20) geomean 21.02n 19.39n -7.78% See #70849 for additional benchmark results, including results for arm64 (which also means without SIMD support). Updates #54766 Updates #70700 Fixes #70849 Change-Id: Ic2361bb6fc15b4436d1d1d5be7e4712e547f611b Reviewed-on: https://go-review.googlesource.com/c/go/+/634396 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-03-27maps: implement faster cloneKeith Randall
│ base │ experiment │ │ sec/op │ sec/op vs base │ MapClone-24 66.802m ± 7% 3.348m ± 2% -94.99% (p=0.000 n=10) Fixes #70836 Change-Id: I9e192b1ee82e18f5580ff18918307042a337fdcc Reviewed-on: https://go-review.googlesource.com/c/go/+/660175 Reviewed-by: Michael Pratt <mpratt@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>
2025-03-26runtime: optimizing memclrNoHeapPointers implementation using SIMD on loong64Guoqi Chen
goos: linux goarch: loong64 pkg: runtime cpu: Loongson-3A6000 @ 2500.00MHz | bench.old | bench.new.256 | | sec/op | sec/op vs base | Memclr/5 3.204n ± 0% 2.804n ± 0% -12.48% (p=0.000 n=10) Memclr/16 3.204n ± 0% 3.204n ± 0% ~ (p=0.465 n=10) Memclr/64 5.267n ± 0% 4.005n ± 0% -23.96% (p=0.000 n=10) Memclr/256 10.280n ± 0% 5.400n ± 0% -47.47% (p=0.000 n=10) Memclr/4096 107.00n ± 1% 30.24n ± 0% -71.74% (p=0.000 n=10) Memclr/65536 1675.0n ± 0% 431.1n ± 0% -74.26% (p=0.000 n=10) Memclr/1M 52.61µ ± 0% 32.82µ ± 0% -37.62% (p=0.000 n=10) Memclr/4M 210.3µ ± 0% 131.3µ ± 0% -37.59% (p=0.000 n=10) Memclr/8M 420.3µ ± 0% 262.5µ ± 0% -37.54% (p=0.000 n=10) Memclr/16M 857.4µ ± 1% 542.9µ ± 3% -36.68% (p=0.000 n=10) Memclr/64M 3.658m ± 3% 2.173m ± 0% -40.59% (p=0.000 n=10) MemclrUnaligned/0_5 4.264n ± 1% 4.359n ± 0% +2.23% (p=0.000 n=10) MemclrUnaligned/0_16 4.595n ± 0% 4.599n ± 0% +0.10% (p=0.020 n=10) MemclrUnaligned/0_64 5.356n ± 0% 5.122n ± 0% -4.37% (p=0.000 n=10) MemclrUnaligned/0_256 10.370n ± 0% 5.907n ± 1% -43.03% (p=0.000 n=10) MemclrUnaligned/0_4096 107.10n ± 0% 37.35n ± 0% -65.13% (p=0.000 n=10) MemclrUnaligned/0_65536 1694.0n ± 0% 441.7n ± 0% -73.93% (p=0.000 n=10) MemclrUnaligned/1_5 4.272n ± 0% 4.348n ± 0% +1.76% (p=0.000 n=10) MemclrUnaligned/1_16 4.593n ± 0% 4.608n ± 0% +0.33% (p=0.002 n=10) MemclrUnaligned/1_64 7.610n ± 0% 5.293n ± 0% -30.45% (p=0.000 n=10) MemclrUnaligned/1_256 12.230n ± 0% 9.012n ± 0% -26.31% (p=0.000 n=10) MemclrUnaligned/1_4096 114.10n ± 0% 39.50n ± 0% -65.38% (p=0.000 n=10) MemclrUnaligned/1_65536 1705.0n ± 0% 468.8n ± 0% -72.50% (p=0.000 n=10) MemclrUnaligned/4_5 4.283n ± 1% 4.346n ± 0% +1.48% (p=0.000 n=10) MemclrUnaligned/4_16 4.599n ± 0% 4.605n ± 0% +0.12% (p=0.000 n=10) MemclrUnaligned/4_64 7.572n ± 1% 5.283n ± 0% -30.24% (p=0.000 n=10) MemclrUnaligned/4_256 12.215n ± 0% 9.212n ± 0% -24.58% (p=0.000 n=10) MemclrUnaligned/4_4096 114.35n ± 0% 39.48n ± 0% -65.47% (p=0.000 n=10) MemclrUnaligned/4_65536 1705.0n ± 0% 469.2n ± 0% -72.48% (p=0.000 n=10) MemclrUnaligned/7_5 4.296n ± 1% 4.349n ± 0% +1.22% (p=0.000 n=10) MemclrUnaligned/7_16 4.601n ± 0% 4.606n ± 0% +0.11% (p=0.004 n=10) MemclrUnaligned/7_64 7.609n ± 0% 5.296n ± 1% -30.39% (p=0.000 n=10) MemclrUnaligned/7_256 12.200n ± 0% 9.011n ± 0% -26.14% (p=0.000 n=10) MemclrUnaligned/7_4096 114.00n ± 0% 39.51n ± 0% -65.34% (p=0.000 n=10) MemclrUnaligned/7_65536 1704.0n ± 0% 469.5n ± 0% -72.45% (p=0.000 n=10) MemclrUnaligned/0_1M 52.57µ ± 0% 32.83µ ± 0% -37.54% (p=0.000 n=10) MemclrUnaligned/0_4M 210.1µ ± 0% 131.3µ ± 0% -37.53% (p=0.000 n=10) MemclrUnaligned/0_8M 420.8µ ± 0% 262.5µ ± 0% -37.62% (p=0.000 n=10) MemclrUnaligned/0_16M 846.2µ ± 0% 528.4µ ± 0% -37.56% (p=0.000 n=10) MemclrUnaligned/0_64M 3.425m ± 1% 2.187m ± 3% -36.16% (p=0.000 n=10) MemclrUnaligned/1_1M 52.56µ ± 0% 32.84µ ± 0% -37.52% (p=0.000 n=10) MemclrUnaligned/1_4M 210.5µ ± 0% 131.3µ ± 0% -37.62% (p=0.000 n=10) MemclrUnaligned/1_8M 420.5µ ± 0% 262.7µ ± 0% -37.53% (p=0.000 n=10) MemclrUnaligned/1_16M 845.2µ ± 0% 528.3µ ± 0% -37.49% (p=0.000 n=10) MemclrUnaligned/1_64M 3.381m ± 0% 2.243m ± 3% -33.66% (p=0.000 n=10) MemclrUnaligned/4_1M 52.56µ ± 0% 32.85µ ± 0% -37.50% (p=0.000 n=10) MemclrUnaligned/4_4M 210.1µ ± 0% 131.3µ ± 0% -37.49% (p=0.000 n=10) MemclrUnaligned/4_8M 420.0µ ± 0% 262.6µ ± 0% -37.48% (p=0.000 n=10) MemclrUnaligned/4_16M 844.8µ ± 0% 528.7µ ± 0% -37.41% (p=0.000 n=10) MemclrUnaligned/4_64M 3.382m ± 1% 2.211m ± 4% -34.63% (p=0.000 n=10) MemclrUnaligned/7_1M 52.59µ ± 0% 32.84µ ± 0% -37.56% (p=0.000 n=10) MemclrUnaligned/7_4M 210.2µ ± 0% 131.3µ ± 0% -37.54% (p=0.000 n=10) MemclrUnaligned/7_8M 420.1µ ± 0% 262.7µ ± 0% -37.47% (p=0.000 n=10) MemclrUnaligned/7_16M 845.1µ ± 0% 528.7µ ± 0% -37.43% (p=0.000 n=10) MemclrUnaligned/7_64M 3.369m ± 0% 2.313m ± 1% -31.34% (p=0.000 n=10) MemclrRange/1K_2K 2707.0n ± 0% 972.4n ± 0% -64.08% (p=0.000 n=10) MemclrRange/2K_8K 8.816µ ± 0% 2.519µ ± 0% -71.43% (p=0.000 n=10) MemclrRange/4K_16K 8.333µ ± 0% 2.240µ ± 0% -73.12% (p=0.000 n=10) MemclrRange/160K_228K 83.47µ ± 0% 31.27µ ± 0% -62.54% (p=0.000 n=10) MemclrKnownSize1 0.4003n ± 0% 0.4004n ± 0% ~ (p=0.119 n=10) MemclrKnownSize2 0.4003n ± 0% 0.4005n ± 0% ~ (p=0.069 n=10) MemclrKnownSize4 0.4003n ± 0% 0.4005n ± 0% ~ (p=0.100 n=10) MemclrKnownSize8 0.4003n ± 0% 0.4004n ± 0% +0.04% (p=0.047 n=10) MemclrKnownSize16 0.8011n ± 0% 0.8012n ± 0% ~ (p=0.926 n=10) MemclrKnownSize32 1.602n ± 0% 1.602n ± 0% ~ (p=0.772 n=10) MemclrKnownSize64 2.405n ± 0% 2.404n ± 0% ~ (p=0.780 n=10) MemclrKnownSize112 2.804n ± 0% 2.804n ± 0% ~ (p=0.538 n=10) MemclrKnownSize128 3.204n ± 0% 3.205n ± 0% ~ (p=0.105 n=10) MemclrKnownSize192 4.808n ± 0% 4.807n ± 0% ~ (p=0.688 n=10) MemclrKnownSize248 6.347n ± 0% 6.346n ± 0% ~ (p=0.133 n=10) MemclrKnownSize256 6.560n ± 0% 6.573n ± 0% +0.19% (p=0.001 n=10) MemclrKnownSize512 13.010n ± 0% 6.809n ± 0% -47.66% (p=0.000 n=10) MemclrKnownSize1024 25.830n ± 0% 8.412n ± 0% -67.43% (p=0.000 n=10) MemclrKnownSize4096 102.70n ± 0% 27.64n ± 0% -73.09% (p=0.000 n=10) MemclrKnownSize512KiB 26.30µ ± 0% 16.42µ ± 0% -37.59% (p=0.000 n=10) geomean 629.8n 393.2n -37.57% Change-Id: I2b9fe834c31d786d2e30cc02c65a6f9c455c4e8d Reviewed-on: https://go-review.googlesource.com/c/go/+/657835 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Meidan Li <limeidan@loongson.cn>
2025-03-24runtime: rename runfinq to runFinalizersAndCleanupsMichael Pratt
Users see this frame in tracebacks and it serves as a hint that what is running here is a finalizer or cleanup. But runfinq is a rather dense name. We can give it a more obvious name to help users realize what it is. For #73011. Change-Id: I6a6a636ce9a493fd00d4b4c60c23f2b1c96d3568 Reviewed-on: https://go-review.googlesource.com/c/go/+/660296 Auto-Submit: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-03-24runtime: always show runfinq in tracebackMichael Pratt
Today, runtime.runfinq is hidden whenever runtime frames are hidden. However this frame serves as a hint that this goroutine is running finalizers, which is otherwise unclear, but can be useful when debugging issues with finalizers. Fixes #73011. Change-Id: I6a6a636cb63951fbe1fefc3554fe9cea5d0a0fb6 Reviewed-on: https://go-review.googlesource.com/c/go/+/660295 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>
2025-03-21runtime: deduplicate context call injection on Windowsqmuntal
Injecting a call to a thread context is complex enough to warrant a dedicated function so that we don't repeat the same code in multiple places. Note that the unix sigctxt struct also follows the same approach. The behavior is unchanged, but the implementation semantics are now clearer by using goarch.StackAlign instead of a mix of goarch.PtrSize, goarch.StackAlign and hardcoded values. While here, fix #68552. Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64 Change-Id: Ic29cd2bf322b520127fecccafd61577076945758 Reviewed-on: https://go-review.googlesource.com/c/go/+/657815 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2025-03-21runtime: fix interactions between synctest, race detector, and timersDamien Neil
When an AfterFunc executes in a synctest bubble, there is a series of happens-before relationships: 1. The AfterFunc is created. 2. The AfterFunc goroutine executes. 3. The AfterFunc goroutine returns. 4. A subsequent synctest.Wait call returns. We were failing to correctly establish the happens-before relationship between the AfterFunc goroutine and the AfterFunc itself being created. When an AfterFunc executes, the G running the timer temporarily switches to the timer heap's racectx. It then calls time.goFunc, which starts a new goroutine to execute the timer. time.goFunc relies on the new goroutine inheriting the racectx of the G running the timer. Normal, non-synctest timers, execute with m.curg == nil, which causes new goroutines to inherit the g0 racectx. We were running synctest timers with m.curg set (to the G executing synctest.Run), so the new AfterFunc goroutine was created using m.curg's racectx. This resulted in us not properly establishing the happens-before relationship between AfterFunc being called and the AfterFunc goroutine starting. Fix this by setting m.curg to nil while executing timers. As one additional fix, when waking a blocked bubble, wake the root goroutine rather than a goroutine blocked in Wait if there is a timer that can fire. Fixes #72750 Change-Id: I2b2d6b0f17f64649409adc93c2603f720494af89 Reviewed-on: https://go-review.googlesource.com/c/go/+/658595 Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-03-20runtime/race: fix reversed conditional in test for fatal map accessDamien Neil
Change-Id: Icc4d90355d8af07fdec852b2adf720f7cfd1edd6 Reviewed-on: https://go-review.googlesource.com/c/go/+/659735 Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-03-20runtime/race: don't complain about unrun tests when fatal map access happensDamien Neil
Fixes #72964 Change-Id: I42c6994fec3b21774bddd1d4d65dc832d9149446 Reviewed-on: https://go-review.googlesource.com/c/go/+/659697 Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-03-20all: use exec.Command.String in test logsqmuntal
There is no need to manually construct a human-friendly string for a exec.Command. The String method does that for us. Change-Id: Iff1033478000bade9cbdc079f6143a7690374258 Reviewed-on: https://go-review.googlesource.com/c/go/+/659475 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-03-19runtime/race: detect when TestRace fails to run all tests, skip failuresDamien Neil
TestRace runs a collection of tests, some of which are expected to fail with data races. Make TestRace more robust at detecting when the test run is cut short, such as when a test causes an unhandled panic. Skip TestRaceRangeFuncIterator, which contains an unhandled panic. This test was causing all subsequent tests to not run. Skip TestNoRaceRangeFuncIterator, which contains an unexpected data race. This test was not running due to the above failure. For #72925 Change-Id: Id662375cc498ea25ae308619709768588bf6a2f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/658875 Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com>
2025-03-19runtime: in asan mode unregister root regions on freeFlorian Zenker
CL 651755 introduced registration of root regions when allocating memory. We also need to unregister that memory to avoid the leak sanitizer accessing unmapped memory. Issue #67833 Change-Id: I5d403d66e65a8a003492f4d79dad22d416fd8574 Reviewed-on: https://go-review.googlesource.com/c/go/+/659135 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2025-03-18runtime, time: don't use monotonic clock inside synctest bubblesDamien Neil
Don't include a monotonic time in time.Times created inside a bubble, to avoid the confusion of different Times using different monotonic clock epochs. For #67434 goos: darwin goarch: arm64 pkg: time cpu: Apple M1 Pro │ /tmp/bench.0 │ /tmp/bench.1 │ │ sec/op │ sec/op vs base │ Since-10 18.42n ± 2% 18.68n ± 1% ~ (p=0.101 n=10) Until-10 18.28n ± 2% 18.46n ± 2% +0.98% (p=0.009 n=10) geomean 18.35n 18.57n +1.20% Change-Id: Iaf1b80d0a4df52139c5b80d4bde4410ef8a49f2f Reviewed-on: https://go-review.googlesource.com/c/go/+/657415 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-03-17runtime: add function runtime.cgoSigtramp support on loong64 and enable ↵limeidan
cgo-traceback testcases Change-Id: I82f6ebd5636bfa112ad3e25dd9b77d7778469a1f Reviewed-on: https://go-review.googlesource.com/c/go/+/604176 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn>
2025-03-17runtime, runtime/cgo: use libc for sigaction syscalls when cgo is enabled on ↵limeidan
loong64 This ensures that runtime's signal handlers pass through the TSAN and MSAN libc interceptors and subsequent calls to the intercepted sigaction function from C will correctly see them. Change-Id: I243a70d9dcb6d95a65c8494d5f9f9f09a316c693 Reviewed-on: https://go-review.googlesource.com/c/go/+/654995 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-03-17runtime: skip TestCgoCallbackPprof on platforms with broken profilingMichael Pratt
CL 658035 added TestCgoCallbackPprof, which is consistently failing on solaris. runtime/pprof maintains a list of platforms where CPU profiling does not work properly. Since this test requires CPU profiling, skip the this test on those platforms. For #72870. Fixes #72876. Change-Id: I6a6a636cbf6b16abcbba8771178fe1d001be9d9b Reviewed-on: https://go-review.googlesource.com/c/go/+/658415 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>
2025-03-15runtime: log profile when mutex profile test failsRhys Hiltner
For #70602 Change-Id: I3f723ebc17ef690d5be7f4f948c9dd1f890196fd Reviewed-on: https://go-review.googlesource.com/c/go/+/658095 Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-03-14runtime: only set isExtraInC if there are no Go frames leftMichael Pratt
mp.isExtraInC is intended to indicate that this M has no Go frames at all; it is entirely executing in C. If there was a cgocallback to Go and then a cgocall to C, such that the leaf frames are C, that is fine. e.g., traceback can handle this fine with SetCgoTraceback (or by simply skipping the C frames). However, we currently mismanage isExtraInC, unconditionally setting it on return from cgocallback. This means that if there are two levels of cgocallback, we end up running Go code with isExtraInC set. 1. C-created thread calls into Go function 1 (via cgocallback). 2. Go function 1 calls into C function 1 (via cgocall). 3. C function 1 calls into Go function 2 (via cgocallback). 4. Go function 2 returns back to C function 1 (returning via the remainder of cgocallback). 5. C function 1 returns back to Go function 1 (returning via the remainder of cgocall). 6. Go function 1 is now running with mp.isExtraInC == true. The fix is simple; only set isExtraInC on return from cgocallback if there are no more Go frames. There can't be more Go frames unless there is an active cgocall out of the Go frames. Fixes #72870. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Change-Id: I6a6a636c4e7ba75a29639d7036c5af3738033467 Reviewed-on: https://go-review.googlesource.com/c/go/+/658035 Reviewed-by: Cherry Mui <cherryyz@google.com> Commit-Queue: Michael Pratt <mpratt@google.com> Auto-Submit: 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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 12:47:10 +0000