aboutsummaryrefslogtreecommitdiff
path: root/src/runtime
AgeCommit message (Collapse)Author
2025-02-05cpu/internal: provide runtime detection of RISC-V extensions on LinuxMark Ryan
Add a RISCV64 variable to cpu/internal that indicates both the presence of RISC-V extensions and performance information about the underlying RISC-V cores. The variable is only populated with non false values on Linux. The detection code relies on the riscv_hwprobe syscall introduced in Linux 6.4. The patch can detect RVV 1.0 and whether the CPU supports fast misaligned accesses. It can only detect RVV 1.0 on a 6.5 kernel or later (without backports). Updates #61416 Change-Id: I2d8289345c885b699afff441d417cae38f6bdc54 Reviewed-on: https://go-review.googlesource.com/c/go/+/522995 Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com>
2025-02-05cmd/go: add rva23u64 as a valid value for GORISCV64Mark Ryan
The RVA23 profile was ratified on the 21st of October 2024. https://riscv.org/announcements/2024/10/risc-v-announces-ratification-of-the-rva23-profile-standard/ Now that it's ratified we can add rva23u64 as a valid value for the GORISCV64 environment variable. This will allow the compiler and assembler to generate instructions made mandatory by the new profile without a runtime check. Examples of such instructions include those introduced by the Vector and Zicond extensions. Setting GORISCV64=rva23u64 defines the riscv64.rva20u64, riscv64.rva22u64 and riscv64.rva23u64 build tags, sets the internal variable buildcfg.GORISCV64 to 23 and defines the macros GORISCV64_rva23u64, hasV, hasZba, hasZbb, hasZbs, hasZfa, and hasZicond for use in assembly language code. Updates #61476 Change-Id: I7641c23084fa52891c9a18df58f4013cb6597d88 Reviewed-on: https://go-review.googlesource.com/c/go/+/633417 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
2025-02-03all: run gofmtIan Lance Taylor
Change-Id: I0af1903ed1e4f2bf4ea273847b024520c577ef6d Reviewed-on: https://go-review.googlesource.com/c/go/+/642496 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> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org>
2025-02-03runtime: fix GODEBUG=gccheckmark=1 and add smoke testMichael Anthony Knyszek
This change fixes GODEBUG=gccheckmark=1 which seems to have bit-rotted. Because the root jobs weren't being reset, it wasn't doing anything. Then, it turned out that checkmark mode would queue up noscan objects in workbufs, which caused it to fail. Then it turned out checkmark mode was broken with user arenas, since their heap arenas are not registered anywhere. Then, it turned out that checkmark mode could just not run properly if the goroutine's preemption flag was set (since sched.gcwaiting is true during the STW). And lastly, it turned out that async preemption could cause erroneous checkmark failures. This change fixes all these issues and adds a simple smoke test to dist to run the runtime tests under gccheckmark, which exercises all of these issues. Fixes #69074. Fixes #69377. Fixes #69376. Change-Id: Iaa0bb7b9e63ed4ba34d222b47510d6292ce168bc Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/608915 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-01-28runtime: mapiter linkname compatibility layerMichael Pratt
This CL reintroduces the various mapiter* linkname functions with a compatibility layer that is careful to maintain compatibility with users of the linkname. The wrappers are straightforward. Callers of these APIs get an extra layer of indirection, with their hiter containing a pointer to the real maps.Iter. These users will take a minor performance hit from the extra allocation, but this approach should have good long-term maintainability. Fixes #71408. Change-Id: I6a6a636c7574bbd670ff5243dfeb63dfba6dc611 Reviewed-on: https://go-review.googlesource.com/c/go/+/643899 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-01-28runtime: rename mapiterinit and mapiternextMichael Pratt
mapiterinit allows external linkname. These users must allocate their own iter struct for initialization by mapiterinit. Since the type is unexported, they also must define the struct themselves. As a result, they of course define the struct matching the old hiter definition (in map_noswiss.go). The old definition is smaller on 32-bit platforms. On those platforms, mapiternext will clobber memory outside of the caller's allocation. On all platforms, the pointer layout between the old hiter and new maps.Iter does not match. Thus the GC may miss pointers and free reachable objects early, or it may see non-pointers that look like heap pointers and throw due to invalid references to free objects. To avoid these issues, we must keep mapiterinit and mapiternext with the old hiter definition. The most straightforward way to do this is to use mapiterinit and mapiternext as a compatibility layer between the old and new iter types. The first step to that is to move normal map use off of these functions, which is what this CL does. Introduce new mapIterStart and mapIterNext functions that replace the former functions everywhere in the toolchain. These have the same behavior as the old functions. This CL temporarily makes the old functions throw to ensure we don't have hidden dependencies on them. We cannot remove them entirely because GOEXPERIMENT=noswissmap still uses the old names, and internal/goobj requires all builtins to exist regardless of GOEXPERIMENT. The next CL will introduce the compatibility layer. I want to avoid using linkname between runtime and reflect, as that would also allow external linknames. So mapIterStart and mapIterNext are duplicated in reflect, which can be done trivially, as it imports internal/runtime/maps. For #71408. Change-Id: I6a6a636c6d4bd1392618c67ca648d3f061afe669 Reviewed-on: https://go-review.googlesource.com/c/go/+/643898 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2025-01-27Revert "runtime: Check LSE support on ARM64 at runtime init"Cherry Mui
This reverts CL 610195. Reason for revert: SIGILL on macOS. See issue #71411. Updates #69124, #60905. Fixes #71411. Change-Id: Ie0624e516dfb32fb13563327bcd7f557e5cba940 Reviewed-on: https://go-review.googlesource.com/c/go/+/644695 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> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
2025-01-22runtime: fix the equality check in AddCleanupCarlos Amedee
This fixes the check that ensures that arg is not equal to ptr in AddCleanup. This also changes any use of throw to panic in AddCleanup. Fixes #71316 Change-Id: Ie5a3e0163b254dff44b7fefedf75207ba587b771 Reviewed-on: https://go-review.googlesource.com/c/go/+/643655 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-01-20runtime: delete out of date commentBill Morgan
Fixes #71328 Change-Id: I5827255bf1f53b8fc4a84fa1accb4089f73d5e8a GitHub-Last-Rev: 26f4eab182130c709be269491049fade3327ddd3 GitHub-Pull-Request: golang/go#71337 Reviewed-on: https://go-review.googlesource.com/c/go/+/643456 Reviewed-by: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> 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>
2025-01-16cmd/internal/obj/wasm, runtime: detect wasmexport call before runtime ↵Cherry Mui
initialization If a wasmexport function is called from the host before initializing the Go Wasm module, currently it will likely fail with a bounds error, because the uninitialized SP is 0, and any SP decrement will make it out of bounds. As at least some Wasm runtime doesn't call _initialize by default, This error can be common. And the bounds error looks confusing to the users. Therefore, we detect this case and emit a clearer error. Fixes #71240. Updates #65199. Change-Id: I107095f08c76cdceb7781ab0304218eab7029ab6 Reviewed-on: https://go-review.googlesource.com/c/go/+/643115 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-01-14internal/runtime/maps: re-enable some testsKeith Randall
Re-enable tests for stack-allocated maps and fast map accessors. Those are implemented now. Update #54766 Change-Id: I8c019702bd9fb077b2fe3f7c78e8e9e10d2263a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/642376 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Keith Randall <khr@golang.org>
2025-01-09runtime/pprof: hide map runtime frames from heap profilesMichael Pratt
Heap profiles hide "runtime" frames like runtime.mapassign. This broke in 1.24 because the map implementation moved to internal/runtime/maps, and runtime/pprof only considered literal "runtime." when looking for runtime frames. It would be nice to use cmd/internal/objabi.PkgSpecial to find runtime packages, but that is hidden away in cmd. Fixes #71174. Change-Id: I6a6a636cb42aa17539e47da16854bd3fd8cb1bfe Reviewed-on: https://go-review.googlesource.com/c/go/+/641775 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-01-08runtime: hold traceAcquire across casgstatus in injectglistMichael Anthony Knyszek
Currently injectglist emits all the trace events before actually calling casgstatus on each goroutine. This is a problem, since tracing can observe an inconsistent state (gstatus does not match tracer's 'emitted an event' state). This change fixes the problem by having injectglist do what every other scheduler function does, and that's wrap each call to casgstatus in traceAcquire/traceRelease. Fixes #70883. Change-Id: I857e96cec01688013597e8efc0c4c3d0b72d3a70 Reviewed-on: https://go-review.googlesource.com/c/go/+/638558 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-12-23cmd/link, runtime: apply a delta to RODATA->DATA relocationsCherry Mui
On AIX, an R_ADDR relocation from an RODATA symbol to a DATA symbol does not work, as the dynamic loader can change the address of the data section, and it is not possible to apply a dynamic relocation to RODATA. In order to get the correct address, we apply the delta between unrelocated and relocated data section addresses at run time. The linker saves both the unrelocated and the relocated addresses, so we can compute the delta. This is possible because RODATA symbols are generated by the compiler and so we have full control of. On AIX, the only case is the on-demand GC pointer masks from the type descriptors, for very large types. Perhaps there is a better way. Fixes #70483. Change-Id: I2664c0a813b38f7b146794cb1e73ccf5e238ca65 Reviewed-on: https://go-review.googlesource.com/c/go/+/638016 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>
2024-12-19runtime/pprof: continued attempt to deflake the VMInfo test.Cosmos Nicolaou
This change catches an additional error message to trigger skipping the test when the underlying system is failing. Fixes #62352 Change-Id: I5c12b20f3e9023597ff89fc905c0646a80ec4811 Reviewed-on: https://go-review.googlesource.com/c/go/+/637995 Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-12-19runtime: test trap panic parsing in TestTracebackSystemMichael Pratt
This mirrors https://go.dev/cl/637755, as x/telemetry is now aware of sigpanic preceding trap frames. For #70637. Change-Id: I13a775f25e89047702d4f2d463ce3210bcf192d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/638015 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-12-16runtime: usleep in TestWeakToStrongMarkTerminationMichael Anthony Knyszek
There's a subtle bug in this test (big surprise): time.Sleep allocates, so the time.Sleep(100*time.Millisecond) before unblocking gcMarkDone might itself end up in gcMarkDone. Work around this by using usleep here instead. Fixes #70532. Change-Id: I4c642ebb12f737cdb0d79ccff64b6059fc3d8b34 Reviewed-on: https://go-review.googlesource.com/c/go/+/636155 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-12-13runtime: migrate missing map linkname allowlistsMichael Pratt
The swissmap implementation forgot to copy some of the linkname allowlists from the old implementation. Copy them from map_noswiss.go. Some were missing linkname entirely; others were linknamed but missing the hall of shame comment. For #54766. Change-Id: Icc715384123e73d868b4cb729ab639abcd6bbfd7 Reviewed-on: https://go-review.googlesource.com/c/go/+/635995 Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-12-10runtime: avoid panic in expired synctest timer chan readDamien Neil
When reading from time.Timer.C for an expired timer using a fake clock (in a synctest bubble), the timer will not be in a heap. Avoid a spurious panic claiming the timer moved between synctest bubbles. Drop the panic when a bubbled goroutine reads from a non-bubbled timer channel: We allow bubbled goroutines to access non-bubbled channels in general. Fixes #70741 Change-Id: I27005e46f4d0067cc6846d234d22766d2e05d163 Reviewed-on: https://go-review.googlesource.com/c/go/+/634955 Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-12-09runtime: make special offset a uintptrMichael Anthony Knyszek
Currently specials try to save on space by only encoding the offset from the base of the span in a uint16. This worked fine up until Go 1.24. - Most specials have an offset of 0 (mem profile, finalizers, etc.) - Cleanups do not care about the offset at all, so even if it's wrong, it's OK. - Weak pointers *do* care, but the unique package always makes a new allocation, so the weak pointer handle offset it makes is always zero. With Go 1.24 and general weak pointers now available, nothing is stopping someone from just creating a weak pointer that is >64 KiB offset from the start of an object, and this weak pointer must be distinct from others. Fix this problem by just increasing the size of a special and making the offset a uintptr, to capture all possible offsets. Since we're in the freeze, this is the safest thing to do. Specials aren't so common that I expect a substantial memory increase from this change. In a future release (or if there is a problem) we can almost certainly pack the special's kind and offset together. There was already a bunch of wasted space due to padding, so this would bring us back to the same memory footprint before this change. Also, add tests for equality of basic weak interior pointers. This works, but we really should've had tests for it. Fixes #70739. Change-Id: Ib49a7f8f0f1ec3db4571a7afb0f4d94c8a93aa40 Reviewed-on: https://go-review.googlesource.com/c/go/+/634598 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Michael Knyszek <mknyszek@google.com> Commit-Queue: Michael Knyszek <mknyszek@google.com>
2024-12-09runtime: remove datadog-agent from prof labels hall of shamePaul Cacheux
github.com/DataDog/datadog-agent has stopped using runtime_setProfLabel and runtime_getProfLabel, remove them from the hall of shame. Updates #67401 Change-Id: I4a66c5e70397d43d7f064aeae5bad064e168316f Reviewed-on: https://go-review.googlesource.com/c/go/+/634476 Auto-Submit: 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> Reviewed-by: Ian Lance Taylor <iant@google.com>
2024-12-07runtime: improve AddCleanup documentationAustin Clements
Steer people from SetFinalizer to AddCleanup. Address some of the *non*-constraints on AddCleanup. Add some of the subtlety from the SetFinalizer documentation to the AddCleanup documentation. Updates #67535. Updates #70425. Change-Id: I8d13b756ca866051b8a5c19327fd5a76f5e0f3d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/634318 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Austin Clements <austin@google.com>
2024-12-06runtime: add note that Callers never returns an entry PCMichael Pratt
The presence of a pc > entry check in CallersFrame implies we might actually see pc == entry, when in reality Callers will never return such a PC. This check is actually just a safety check for avoid reporting completely nonsensical from bad input. all.bash reports two violations to this invariant: TestCallersFromWrapper, which explicitly constructs a CallersFrame input with an entry PC. runtime/pprof.printStackRecord, which passes pprof stacks to CallersFrame (technically not a valid use of CallersFrames!). runtime/pprof.(*Profile).Add can add the entry PC of runtime/pprof.lostProfileEvent to samples. (CPU profiles do lostProfileEvent + 1. I will send a second CL to fix Add.) Change-Id: Iac2a2f0c15117d4a383bd84cddf0413b2d7dd3ef Reviewed-on: https://go-review.googlesource.com/c/go/+/634315 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>
2024-12-04runtime: remove "hall of shame" comment from public documentationAlexey Palazhchenko
See https://pkg.go.dev/runtime@go1.23.4#FuncForPC The updated comment uses the same format as bytes.Repeat and math.Float32bits. Change-Id: Idfbc38645e6b0f03fb07f294c4c79b997d9a01a1 GitHub-Last-Rev: 00fa155c75fb625be84edeadff49276e6cddc42c GitHub-Pull-Request: golang/go#70671 Reviewed-on: https://go-review.googlesource.com/c/go/+/633475 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-12-03runtime: avoid defer on system stack in synctestidle_cDamien Neil
Fixes #70661 Change-Id: I58a465cfb1cd16709ffbb072eca0997569540074 Reviewed-on: https://go-review.googlesource.com/c/go/+/633281 Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-30crypto/x509: keep RSA CRT values in ParsePKCS1PrivateKeyFilippo Valsorda
Turns out that recomputing them (and qInv in particular) in constant time is expensive, so let's not throw them away when they are available. They are much faster to check, so we now do that on precompute. Also, thanks to the opaque crypto/internal/fips140/rsa.PrivateKey type, we now have some assurance that the values we use are always ones we checked. Recovers most of the performance loss since CL 630516 in the happy path. Also, since now we always use the CRT, if necessary by running a throwaway Precompute, which is now cheap if PrecomputedValues is filled out, we effectively fixed the JSON round-trip slowdown (#59695). goos: darwin goarch: arm64 pkg: crypto/rsa cpu: Apple M2 │ 3b42687c56 │ f017604bc6-dirty │ │ sec/op │ sec/op vs base │ ParsePKCS8PrivateKey/2048-8 26.76µ ± 1% 65.99µ ± 1% +146.64% (p=0.002 n=6) Fixes #59695 Updates #69799 For #69536 Change-Id: I507f8c5a32e69ab28990a3bf78959836b9b08cc9 Reviewed-on: https://go-review.googlesource.com/c/go/+/632478 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2024-11-25runtime: using ABIInternal on syscall for riscv64Meng Zhuo
Change-Id: I550e6b9682df3a3ef75fba6da95c92a30da7bb22 Reviewed-on: https://go-review.googlesource.com/c/go/+/620755 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>
2024-11-22runtime: properly search for cleanups in cleanup.stopCarlos Amedee
This change modifies the logic which searches for existing cleanups. The existing search logic sets the next node to the current node in certain conditions. This would cause future searches to loop endlessly. The existing loop could convert non-cleanup specials into cleanups and cause data corruption. This also changes where we release the m while we are adding a cleanup. We are currently holding onto an p-specific gcwork after releasing the m. Change-Id: I0ac0b304f40910549c8df114e523c89d9f0d7a75 Reviewed-on: https://go-review.googlesource.com/c/go/+/630278 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Carlos Amedee <carlos@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-11-22runtime, internal/synctest, syscall/js: keep bubble membership in syscallsDamien Neil
Propagate synctest bubble membership through syscall/js.Func functions. Avoids panics from cross-bubble channel operations in js syscalls. Fixes #70512 Change-Id: Idbd9f95da8bc4f055a635dfac041359f848dad1a Reviewed-on: https://go-review.googlesource.com/c/go/+/631055 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com>
2024-11-22crypto/rsa: refuse to generate and/or use keys smaller than 1024 bitsFilippo Valsorda
Fixes #68762 Change-Id: Id89c770571d7cc27c6cf7932139ec3424383a7ef Reviewed-on: https://go-review.googlesource.com/c/go/+/629938 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-21all: fix some function names and typos in commentcuishuang
Change-Id: I07e7c8eaa5bd4bac0d576b2f2f4cd3f81b0b77a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/630055 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Commit-Queue: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com>
2024-11-21runtime: utilize EVFILT_USER more effectivelyMaksym Sobolyev
Re-work kqueue_event wakeup logic to use one-shot events. In an event of waking up a wrong thread, simply re-post the event. This saves close to 1 system call per wakeup on average, since chances of non-blocking poller picking it up is pretty low. Change-Id: I202d0d57a31d91ac5354ea075215f647c65790d3 GitHub-Last-Rev: e707d4732683702bd2989f07230a2f34354c288b GitHub-Pull-Request: golang/go#70408 Reviewed-on: https://go-review.googlesource.com/c/go/+/628975 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2024-11-20runtime: clean up new lock2 structureRhys Hiltner
Simplify some flow control, as suggested on https://go.dev/cl/620435. The MutexCapture microbenchmark shows a bit of throughput improvement at moderate levels of contention, and little change to capture and starvation. (Note that the capture and starvation figures below are in terms of power-of-two buckets multiplied by throughput, so they either follow similar patterns or move by a factor of two.) For #68578 goos: linux goarch: amd64 pkg: runtime cpu: 13th Gen Intel(R) Core(TM) i7-13700H │ old │ new │ │ sec/op │ sec/op vs base │ MutexCapture 18.21n ± 0% 18.35n ± 0% +0.77% (p=0.000 n=10) MutexCapture-2 21.46n ± 8% 21.05n ± 12% ~ (p=0.796 n=10) MutexCapture-3 22.56n ± 9% 22.59n ± 18% ~ (p=0.631 n=10) MutexCapture-4 22.85n ± 5% 22.74n ± 2% ~ (p=0.565 n=10) MutexCapture-5 22.84n ± 5% 22.50n ± 14% ~ (p=0.912 n=10) MutexCapture-6 23.33n ± 14% 22.22n ± 3% -4.78% (p=0.004 n=10) MutexCapture-7 27.04n ± 14% 23.78n ± 15% ~ (p=0.089 n=10) MutexCapture-8 25.44n ± 10% 23.03n ± 6% -9.48% (p=0.004 n=10) MutexCapture-9 25.56n ± 7% 24.39n ± 11% ~ (p=0.218 n=10) MutexCapture-10 26.77n ± 10% 24.00n ± 7% -10.33% (p=0.023 n=10) MutexCapture-11 27.02n ± 7% 24.55n ± 15% -9.18% (p=0.035 n=10) MutexCapture-12 26.71n ± 8% 24.96n ± 8% ~ (p=0.148 n=10) MutexCapture-13 25.58n ± 4% 25.82n ± 5% ~ (p=0.271 n=10) MutexCapture-14 26.86n ± 6% 25.91n ± 7% ~ (p=0.529 n=10) MutexCapture-15 25.12n ± 13% 26.16n ± 4% ~ (p=0.353 n=10) MutexCapture-16 26.18n ± 4% 26.21n ± 9% ~ (p=0.838 n=10) MutexCapture-17 26.04n ± 4% 25.85n ± 5% ~ (p=0.363 n=10) MutexCapture-18 26.02n ± 7% 25.93n ± 5% ~ (p=0.853 n=10) MutexCapture-19 25.67n ± 5% 26.21n ± 4% ~ (p=0.631 n=10) MutexCapture-20 25.50n ± 6% 25.99n ± 8% ~ (p=0.404 n=10) geomean 24.73n 24.02n -2.88% │ old │ new │ │ sec/streak-p90 │ sec/streak-p90 vs base │ MutexCapture 76.36m ± 0% 76.96m ± 0% +0.79% (p=0.000 n=10) MutexCapture-2 10.609µ ± 50% 5.390µ ± 119% ~ (p=0.579 n=10) MutexCapture-3 5.936µ ± 93% 5.782µ ± 18% ~ (p=0.684 n=10) MutexCapture-4 5.849µ ± 5% 5.820µ ± 2% ~ (p=0.579 n=10) MutexCapture-5 5.849µ ± 5% 5.759µ ± 14% ~ (p=0.912 n=10) MutexCapture-6 5.975µ ± 14% 5.687µ ± 3% -4.81% (p=0.004 n=10) MutexCapture-7 6.921µ ± 14% 6.086µ ± 18% ~ (p=0.165 n=10) MutexCapture-8 6.512µ ± 10% 5.894µ ± 6% -9.50% (p=0.004 n=10) MutexCapture-9 6.544µ ± 7% 6.245µ ± 11% ~ (p=0.218 n=10) MutexCapture-10 6.962µ ± 11% 6.144µ ± 7% -11.76% (p=0.023 n=10) MutexCapture-11 6.938µ ± 7% 6.284µ ± 130% ~ (p=0.190 n=10) MutexCapture-12 6.838µ ± 8% 6.408µ ± 13% ~ (p=0.404 n=10) MutexCapture-13 6.549µ ± 4% 6.608µ ± 5% ~ (p=0.271 n=10) MutexCapture-14 6.877µ ± 8% 6.634µ ± 7% ~ (p=0.436 n=10) MutexCapture-15 6.433µ ± 13% 6.697µ ± 4% ~ (p=0.247 n=10) MutexCapture-16 6.702µ ± 10% 6.711µ ± 116% ~ (p=0.796 n=10) MutexCapture-17 6.730µ ± 3% 6.619µ ± 5% ~ (p=0.225 n=10) MutexCapture-18 6.663µ ± 7% 6.716µ ± 13% ~ (p=0.853 n=10) MutexCapture-19 6.570µ ± 5% 6.710µ ± 4% ~ (p=0.529 n=10) MutexCapture-20 6.528µ ± 6% 6.775µ ± 11% ~ (p=0.247 n=10) geomean 10.66µ 10.00µ -6.13% │ old │ new │ │ sec/starve-p90 │ sec/starve-p90 vs base │ MutexCapture-2 10.609µ ± 50% 5.390µ ± 119% ~ (p=0.579 n=10) MutexCapture-3 184.8µ ± 91% 183.9µ ± 48% ~ (p=0.436 n=10) MutexCapture-4 388.8µ ± 270% 375.6µ ± 280% ~ (p=0.436 n=10) MutexCapture-5 807.2µ ± 83% 2880.9µ ± 85% ~ (p=0.105 n=10) MutexCapture-6 2.272m ± 61% 2.173m ± 34% ~ (p=0.280 n=10) MutexCapture-7 1.351m ± 125% 2.990m ± 70% ~ (p=0.393 n=10) MutexCapture-8 3.328m ± 97% 3.064m ± 96% ~ (p=0.739 n=10) MutexCapture-9 3.526m ± 91% 3.081m ± 47% -12.62% (p=0.015 n=10) MutexCapture-10 3.641m ± 86% 3.228m ± 90% -11.34% (p=0.005 n=10) MutexCapture-11 3.324m ± 109% 3.190m ± 71% ~ (p=0.481 n=10) MutexCapture-12 3.519m ± 77% 3.200m ± 106% ~ (p=0.393 n=10) MutexCapture-13 3.353m ± 91% 3.368m ± 99% ~ (p=0.853 n=10) MutexCapture-14 3.314m ± 101% 3.396m ± 286% ~ (p=0.353 n=10) MutexCapture-15 3.534m ± 83% 3.397m ± 91% ~ (p=0.739 n=10) MutexCapture-16 3.485m ± 90% 3.436m ± 116% ~ (p=0.853 n=10) MutexCapture-17 6.516m ± 48% 3.452m ± 88% ~ (p=0.190 n=10) MutexCapture-18 6.645m ± 105% 3.439m ± 108% ~ (p=0.218 n=10) MutexCapture-19 6.521m ± 46% 4.907m ± 42% ~ (p=0.529 n=10) MutexCapture-20 6.532m ± 47% 3.516m ± 89% ~ (p=0.089 n=10) geomean 1.919m 1.783m -7.06% Change-Id: I36106e1baf8afd132f1568748d1b83b797fa260e Reviewed-on: https://go-review.googlesource.com/c/go/+/629415 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
2024-11-20internal/byteorder: use canonical Go casing in namesRuss Cox
If Be and Le stand for big-endian and little-endian, then they should be BE and LE. Change-Id: I723e3962b8918da84791783d3c547638f1c9e8a9 Reviewed-on: https://go-review.googlesource.com/c/go/+/627376 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-20all: rename crypto/internal/fips to crypto/internal/fips140Russ Cox
Sometimes we've used the 140 suffix (GOFIPS140, crypto/fips140) and sometimes not (crypto/internal/fips, cmd/go/internal/fips). Use it always, to avoid having to remember which is which. Also, there are other FIPS standards, like AES (FIPS 197), SHA-2 (FIPS 180), and so on, which have nothing to do with FIPS 140. Best to be clear. For #70123. Change-Id: I33b29dabd9e8b2703d2af25e428f88bc81c7c307 Reviewed-on: https://go-review.googlesource.com/c/go/+/630115 Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2024-11-20runtime: keep cleanup closure alive across adding the cleanup specialMichael Anthony Knyszek
This is similar to the weak handle bug in #70455. In short, there's a window where a heap-allocated value is only visible through a special that has not been made visible to the GC yet. For #70455. Change-Id: Ic2bb2c60d422a5bc5dab8d971cfc26ff6d7622bc Reviewed-on: https://go-review.googlesource.com/c/go/+/630277 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2024-11-20runtime: explicitly keep handle alive during getOrAddWeakHandleMichael Anthony Knyszek
getOrAddWeakHandle is very careful about keeping its input alive across the operation, but not very careful about keeping the heap-allocated handle it creates alive. In fact, there's a window in this function where it is *only* visible via the special. Specifically, the window of time between when the handle is stored in the special and when the special actually becomes visible to the GC. (If we fail to add the special because it already exists, that case is fine. We don't even use the same handle value, but the one we obtain from the attached GC-visible special, *and* we return that value, so it remains live.) Fixes #70455. Change-Id: Iadaff0cfb93bcaf61ba2b05be7fa0519c481de82 Reviewed-on: https://go-review.googlesource.com/c/go/+/630315 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2024-11-20crypto/x509: remove x509sha1 GODEBUGRoland Shoemaker
Fixes #41682 Change-Id: I37760f2186e75ec7df9674db25ae466cf453d66d Reviewed-on: https://go-review.googlesource.com/c/go/+/629676 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-11-20runtime: remove unused casgcopystack functionDamien Neil
Change-Id: I349b24ba5259d7abb0ae37065f704517aa4decda Reviewed-on: https://go-review.googlesource.com/c/go/+/630155 Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-20runtime: avoid deadlock in synctest changegstatus when copying stacksDamien Neil
For #67434 Fixes #70452 Change-Id: Ie655a9e55837aa68b6bfb0bb69b6c8caaf3bbea5 Reviewed-on: https://go-review.googlesource.com/c/go/+/629856 Reviewed-by: Russ Cox <rsc@golang.org> 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>
2024-11-19internal/synctest: new package for testing concurrent codeDamien Neil
Add an internal (for now) implementation of testing/synctest. The synctest.Run function executes a tree of goroutines in an isolated environment using a fake clock. The synctest.Wait function allows a test to wait for all other goroutines within the test to reach a blocking point. For #67434 For #69687 Change-Id: Icb39e54c54cece96517e58ef9cfb18bf68506cfc Reviewed-on: https://go-review.googlesource.com/c/go/+/591997 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-19runtime: use indirect call in adjustSignalStack to avoid nosplit overflowDamien Neil
Avoids a nosplit stack overflow on OpenBSD after CL 591997 increases the adjustSignalStack stack by 16 bytes. Change-Id: I2c990de6c7cd8d2aca6e6b98133da120c8a4174b Reviewed-on: https://go-review.googlesource.com/c/go/+/629696 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-19crypto/subtle: add DIT closureRoland Shoemaker
Add a new function, WithDataIndependentTiming, which takes a function as an argument, and encloses it with calls to set/unset the DIT PSTATE bit on Arm64. Since DIT is OS thread-local, for the duration of the execution of WithDataIndependentTiming, we lock the goroutine to the OS thread, using LockOSThread. For long running operations, this is likely to not be performant, but we expect this to be tightly scoped around cryptographic operations that have bounded execution times. If locking to the OS thread turns out to be too slow, another option is to add a bit to the g state indicating if a goroutine has DIT enabled, and then have the scheduler enable/disable DIT when scheduling a g. Additionally, we add a new GODEBUG, dataindependenttiming, which allows setting DIT for an entire program. Running a program with dataindependenttiming=1 enables DIT for the program during initialization. In an ideal world PSTATE.DIT would be inherited from the parent thread, so we'd only need to set it in the main thread and then all subsequent threads would inherit the value. While this does happen in the Linux kernel [0], it is not the case for darwin [1]. Rather than add complex logic to only set it on darwin for each new thread, we just unconditionally set it in mstart1 and cgocallbackg1 regardless of the OS. DIT will already impose some overhead, and the cost of setting the bit is only ~two instructions (CALL, MSR), so it should be cheap enough. Fixes #66450 Updates #49702 [0] https://github.com/torvalds/linux/blob/e8bdb3c8be08c9a3edc0a373c0aa8729355a0705/arch/arm64/kernel/process.c#L373 [1] https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/osfmk/arm64/status.c#L1666 Change-Id: I78eda691ff9254b0415f2b54770e5850a0179749 Reviewed-on: https://go-review.googlesource.com/c/go/+/598336 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-19cmd/go: re-enable build JSON from go test -json, now with GODEBUGAustin Clements
This re-enables the behavior of CL 536399 (by effectively reverting CL 628955), so now go test -json again includes build output and failures as JSON rather than text. However, since this behavior is clearly enough to trip up some build systems, this CL includes a GODEBUG=gotestjsonbuildtext that can be set to 1 to revert to the old behavior. Fixes #70402. Updates #62067. Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64_13,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest Change-Id: I84e778cd844783dacfc83433e391b5ccb5925127 Reviewed-on: https://go-review.googlesource.com/c/go/+/629335 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> Auto-Submit: Austin Clements <austin@google.com>
2024-11-19cmd/compiler,internal/runtime/atomic: optimize Cas{64,32} on loong64Guoqi Chen
In Loongson's new microstructure LA664 (Loongson-3A6000) and later, the atomic compare-and-exchange instruction AMCAS[DB]{B,W,H,V} [1] is supported. Therefore, the implementation of the atomic operation compare-and-swap can be selected according to the CPUCFG flag LAMCAS: AMCASDB(full barrier) instruction is used on new microstructures, and traditional LL-SC is used on LA464 (Loongson-3A5000) and older microstructures. This can significantly improve the performance of Go programs on new microstructures. goos: linux goarch: loong64 pkg: internal/runtime/atomic cpu: Loongson-3A6000 @ 2500.00MHz | bench.old | bench.new | | sec/op | sec/op vs base | Cas 46.84n ± 0% 22.82n ± 0% -51.28% (p=0.000 n=20) Cas-2 47.58n ± 0% 29.57n ± 0% -37.85% (p=0.000 n=20) Cas-4 43.27n ± 20% 25.31n ± 13% -41.50% (p=0.000 n=20) Cas64 46.85n ± 0% 22.82n ± 0% -51.29% (p=0.000 n=20) Cas64-2 47.43n ± 0% 29.53n ± 0% -37.74% (p=0.002 n=20) Cas64-4 43.18n ± 0% 25.28n ± 2% -41.46% (p=0.000 n=20) geomean 45.82n 25.74n -43.82% goos: linux goarch: loong64 pkg: internal/runtime/atomic cpu: Loongson-3A5000 @ 2500.00MHz | bench.old | bench.new | | sec/op | sec/op vs base | Cas 50.05n ± 0% 51.26n ± 0% +2.42% (p=0.000 n=20) Cas-2 52.80n ± 0% 53.11n ± 0% +0.59% (p=0.000 n=20) Cas-4 55.97n ± 0% 57.31n ± 0% +2.39% (p=0.000 n=20) Cas64 50.05n ± 0% 51.26n ± 0% +2.42% (p=0.000 n=20) Cas64-2 52.68n ± 0% 53.11n ± 0% +0.82% (p=0.000 n=20) Cas64-4 55.96n ± 0% 57.26n ± 0% +2.33% (p=0.000 n=20) geomean 52.86n 53.83n +1.82% [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html Change-Id: I9b777c63c124fb492f61c903f77061fa2b4e5322 Reviewed-on: https://go-review.googlesource.com/c/go/+/613396 Reviewed-by: Meidan Li <limeidan@loongson.cn> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Qiqi Huang <huangqiqi@loongson.cn> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-19crypto/rand: move OS interaction to crypto/internal/sysrandFilippo Valsorda
We're going to use that package as the passive entropy source for the FIPS module, and we need to import it from a package that will be imported by crypto/rand. Since there is no overridable Reader now, introduced a mechanism to test the otherwise impossible failure of the OS entropy source. For #69536 Change-Id: I558687ed1ec896dba05b99b937970bb809de3fe7 Reviewed-on: https://go-review.googlesource.com/c/go/+/624976 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-11-18weak: move internal/weak to weak, and update according to proposalMichael Anthony Knyszek
The updates are: - API documentation changes. - Removal of the old package documentation discouraging linkname. - Addition of new package documentation with some advice. - Renaming of weak.Pointer.Strong -> weak.Pointer.Value. Fixes #67552. Change-Id: Ifad7e629b6d339dacaf2ca37b459d7f903e31bf8 Reviewed-on: https://go-review.googlesource.com/c/go/+/628455 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2024-11-18runtime: get rid of gc programs for typesKeith Randall
Instead, have the runtime build the gc bitmaps on demand at runtime. Change-Id: If7a245bc62e4bce3ce80972410b0ed307d921abe Reviewed-on: https://go-review.googlesource.com/c/go/+/616255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com>
2024-11-18internal/sync: move sync.Mutex implementation into new packageMichael Anthony Knyszek
This CL refactors sync.Mutex such that its implementation lives in the new internal/sync package. The purpose of this change is to eventually reverse the dependency edge between internal/concurrent and sync, such that sync can depend on internal/concurrent (or really, its contents, which will likely end up in internal/sync). The only change made to the sync.Mutex code is the frame skip count for mutex profiling, so that the internal/sync frames are omitted in the profile. Change-Id: Ib3603d30e8e71508c4ea883a584ae2e51ce40c3f Reviewed-on: https://go-review.googlesource.com/c/go/+/594056 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2024-11-18cmd/compile: remove gc programs from stack frame objectsKeith Randall
This is a two-pronged approach. First, try to keep large objects off the stack frame. Second, if they do manage to appear anyway, use straight bitmasks instead of gc programs. Generally probably a good idea to keep large objects out of stack frames. But particularly keeping gc programs off the stack simplifies runtime code a bit. This CL sets the limit of most stack objects to 131072 bytes (on 64-bit archs). There can still be large objects if allocated by a late pass, like order, or they are required to be on the stack, like function arguments. But the size for the bitmasks for these objects isn't a huge deal, as we have already have (probably several) bitmasks for the frame liveness map itself. Change-Id: I6d2bed0e9aa9ac7499955562c6154f9264061359 Reviewed-on: https://go-review.googlesource.com/c/go/+/542815 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 17:58:35 +0000