go/src/runtime/debug.go, branch fix-runtime-test-GOMAXPROCS

internal/testenv: exclude GOMAXPROCS when building test program

2025-07-20T06:09:31Z

In the environment where GOMAXPROCS set explicitly, for example to 3 in shell profile, the runtime tests will fail with the following error, ---- ok regexp/syntax 0.428s --- FAIL: TestCgroupGOMAXPROCS (0.81s) crash_test.go:186: running /home/ms/src/go/bin/go build -o /tmp/go-build1753772192/testprog.exe crash_test.go:208: built testprog in 796.664277ms --- FAIL: TestCgroupGOMAXPROCS/containermaxprocs=0 (0.00s) cgroup_linux_test.go:60: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (907.06µs): ok cgroup_linux_test.go:63: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSNoLimit (0.00s) cgroup_linux_test.go:82: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (879.194µs): ok cgroup_linux_test.go:85: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSHigherThanNumCPU (0.00s) cgroup_linux_test.go:102: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.396µs): ok cgroup_linux_test.go:105: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSRound (0.01s) --- FAIL: TestCgroupGOMAXPROCSRound/50000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.099µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/100000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (894.001µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/150000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (850.897µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSSchedAffinity (0.00s) cgroup_linux_test.go:229: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (867.987µs): ok cgroup_linux_test.go:232: output got "3\n" want "2\n" FAIL FAIL runtime 23.088s ---- This changes exclude the GOMAXPROCS when building program for testing so it does not affect the tests. Change-Id: I590d9eca57026539413cf4c93b37f624f179d534

runtime: expand GOMAXPROCS documentation

2025-07-15T06:13:25Z

Expand the GOMAXPROCS documentation to include details of how defaults are selected, as this is something that inquisitive minds will want to know. I've added an additional warning that these details may changed. While we are here, add a bit more structure to make it easier to find the relevant parts of the documentation. For #73193. Change-Id: I6a6a636cae93237e3e3174822490d51805e70990 Reviewed-on: https://go-review.googlesource.com/c/go/+/685318 Reviewed-by: Dmitri Shuralyov Auto-Submit: Sean Liao Reviewed-by: Sean Liao LUCI-TryBot-Result: Go LUCI Reviewed-by: Carlos Amedee

runtime: note custom GOMAXPROCS even if value doesn't change

2025-06-25T15:55:42Z

When an application calls runtime.GOMAXPROCS(runtime.GOMAXPROCS(0)), the runtime does not need to change the actual GOMAXPROCS value (via STW). However, this call must still transition from "automatic" to "custom" GOMAXPROCS state, thus disabling background updates. Thus this case shouldn't return quite as early as it currently does. Change-Id: I6a6a636c42f73996532bd9f7beb95e933256c9e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/683815 Reviewed-by: Michael Knyszek Reviewed-by: Carlos Amedee LUCI-TryBot-Result: Go LUCI Auto-Submit: Michael Pratt

runtime: guarantee no GOMAXPROCS update syscalls after GOMAXPROCS call

2025-05-29T17:55:39Z

We already guarantee that no automatic updates to GOMAXPROCS occur after a GOMAXPROCS call returns. This is easily achieved by having the update goroutine double-check that updates are still allowed during STW before committing the new value. However, it is possible for sysmon to concurrently run defaultGOMAXPROCS to compute a new GOMAXPROCS value after GOMAXPROCS returns. This new value will be discarded later, but we'll still perform the system calls necessary to compute the new value. Normally this distinction doesn't matter, but if you want to sandbox a Go program, then you may want to disable GOMAXPROCS updates to reduce the system call footprint. A call to GOMAXPROCS will disable updates, but without a guarantee on when sysmon will observe the change it is somewhat fragile. Add explicit synchronization between GOMAXPROCS and sysmon to guarantee that sysmon won't run defaultGOMAXPROCS after GOMAXPROCS returns. The synchronization is a bit complex because we can't hold a mutex across STW, nor take a semaphore from sysmon, but the result isn't too bad. One oddity is that sched.customGOMAXPROCS and gomaxprocs are no longer updated in lockstep (even though both are protected by sched.lock), but I don't believe anything should depend on that. For #73193. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-staticlockranking Change-Id: I6a6a636cff243a9b69ac1b5d2f98925648e60236 Reviewed-on: https://go-review.googlesource.com/c/go/+/677037 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek

runtime: use cgroup CPU limit to set GOMAXPROCS

2025-05-21T17:21:55Z

This CL adds two related features enabled by default via compatibility GODEBUGs containermaxprocs and updatemaxprocs. On Linux, containermaxprocs makes the Go runtime consider cgroup CPU bandwidth limits (quota/period) when setting GOMAXPROCS. If the cgroup limit is lower than the number of logical CPUs available, then the cgroup limit takes precedence. On all OSes, updatemaxprocs makes the Go runtime periodically recalculate the default GOMAXPROCS value and update GOMAXPROCS if it has changed. If GOMAXPROCS is set manually, this update does not occur. This is intended primarily to detect changes to cgroup limits, but it applies on all OSes because the CPU affinity mask can change as well. The runtime only considers the limit in the leaf cgroup (the one that actually contains the process), caching the CPU limit file descriptor(s), which are periodically reread for updates. This is a small departure from the original proposed design. It will not consider limits of parent cgroups (which may be lower than the leaf), and it will not detection cgroup migration after process start. We can consider changing this in the future, but the simpler approach is less invasive; less risk to packages that have some awareness of runtime internals. e.g., if the runtime periodically opens new files during execution, file descriptor leak detection is difficult to implement in a stable way. For #73193. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Change-Id: I6a6a636c631c1ae577fb8254960377ba91c5dc98 Reviewed-on: https://go-review.googlesource.com/c/go/+/670497 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek

runtime: rename ncpu to numCPUStartup

2025-05-19T19:47:30Z

ncpu is the total logical CPU count at startup. It is never updated. For #73193, we will start using updated CPU counts for updated GOMAXPROCS, making the ncpu name a bit ambiguous. Change to a less ambiguous name. While we're at it, give the OS specific lookup functions a common name, so it can be used outside of osinit later. For #73193. Change-Id: I6a6a636cf21cc60de36b211f3c374080849fc667 Reviewed-on: https://go-review.googlesource.com/c/go/+/672277 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek Auto-Submit: Michael Pratt

runtime: add runtime.debugPinnerV1

2024-05-11T20:38:24Z

Adds runtime.debugPinnerV1 which returns a runtime.Pinner object that pins itself. This is intended to be used by debuggers in conjunction with runtime.debugCall to keep heap memory reachable even if it isn't referenced from anywhere else. Change-Id: I508ee6a7b103e68df83c96f2e04a0599200300dc Reviewed-on: https://go-review.googlesource.com/c/go/+/558276 Reviewed-by: Cherry Mui LUCI-TryBot-Result: Go LUCI Reviewed-by: Austin Clements

runtime: migrate internal/atomic to internal/runtime

2024-03-25T19:53:03Z

For #65355 Change-Id: I65dd090fb99de9b231af2112c5ccb0eb635db2be Reviewed-on: https://go-review.googlesource.com/c/go/+/560155 Reviewed-by: David Chase Reviewed-by: Michael Pratt LUCI-TryBot-Result: Go LUCI Reviewed-by: Ibrahim Bazoka Auto-Submit: Emmanuel Odeke

runtime: profile contended lock calls

2023-11-21T21:02:20Z

Add runtime-internal locks to the mutex contention profile. Store up to one call stack responsible for lock contention on the M, until it's safe to contribute its value to the mprof table. Try to use that limited local storage space for a relatively large source of contention, and attribute any contention in stacks we're not able to store to a sentinel _LostContendedLock function. Avoid ballooning lock contention while manipulating the mprof table by attributing to that sentinel function any lock contention experienced while reporting lock contention. Guard collecting real call stacks with GODEBUG=profileruntimelocks=1, since the available data has mixed semantics; we can easily capture an M's own wait time, but we'd prefer for the profile entry of each critical section to describe how long it made the other Ms wait. It's too late in the Go 1.22 cycle to make the required changes to futex-based locks. When not enabled, attribute the time to the sentinel function instead. Fixes #57071 This is a roll-forward of https://go.dev/cl/528657, which was reverted in https://go.dev/cl/543660 Reason for revert: de-flakes tests (reduces dependence on fine-grained timers, correctly identifies contention on big-endian futex locks, attempts to measure contention in the semaphore implementation but only uses that secondary measurement to finish the test early, skips tests on single-processor systems) Change-Id: I31389f24283d85e46ad9ba8d4f514cb9add8dfb0 Reviewed-on: https://go-review.googlesource.com/c/go/+/544195 Reviewed-by: Michael Pratt LUCI-TryBot-Result: Go LUCI TryBot-Result: Gopher Robot Reviewed-by: Than McIntosh Auto-Submit: Rhys Hiltner Run-TryBot: Rhys Hiltner

Revert "runtime: profile contended lock calls"

2023-11-20T13:20:29Z

This reverts commit go.dev/cl/528657. Reason for revert: broke a lot of builders. Change-Id: I70c33062020e997c4df67b3eaa2e886cf0da961e Reviewed-on: https://go-review.googlesource.com/c/go/+/543660 Reviewed-by: Than McIntosh Auto-Submit: Matthew Dempsky LUCI-TryBot-Result: Go LUCI