aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/pprof/pprof.go
AgeCommit message (Collapse)Author
37 hoursruntime/pprof: using buffer writer instead of original writerWeixie Cui
Change-Id: Ibff8e7a08090d67d9a0625dee068c8d2eefbd190 GitHub-Last-Rev: b90b986121314615cf5d259d76a7be59303de1b0 GitHub-Pull-Request: golang/go#78630 Reviewed-on: https://go-review.googlesource.com/c/go/+/765480 Reviewed-by: Florian Lehner <lehner.florian86@gmail.com> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-28runtime: remove redundant fields from memory profile recordsNick Ripley
The memProfCycle struct holds allocation counts and bytes allocated, and frees and bytes freed. But the memory profile records are already aggregated by allocation size, which is stored in the "size" field of the bucket struct. We can derive the bytes allocated/freed using the counts and the size we already store. Thus we can delete the bytes fields from memProfCycle, saving 64 bytes per memRecord. We can do something similar for the profilerecord.MemProfileRecord type. We just need to know the object size and we can derive the allocated and freed bytes accordingly. Change-Id: I103885c2f29471b25283e330674fc16d6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/760140 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2026-02-09runtime/pprof: fix missing Profile docsAustin Clements
CL 688335 accidentally introduced a blank line between the Profile doc comment and the type definition, causing the entire doc to get dropped. Change-Id: I97b1c0e57d142d7caea6e543a0138ed6dcd1c3fe Reviewed-on: https://go-review.googlesource.com/c/go/+/743660 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Austin Clements <austin@google.com>
2025-11-24runtime: add GODEBUG=tracebacklabels=1 to include pprof labels in tracebacksDavid Finkel
Copy LabelSet to an internal package as label.Set, and include (escaped) labels within goroutine stack dumps. Labels are added to the goroutine header as quoted key:value pairs, so the line may get long if there are a lot of labels. To handle escaping, we add a printescaped function to the runtime and hook it up to the print function in the compiler with a new runtime.quoted type that's a sibling to runtime.hex. (in fact, we leverage some of the machinery from printhex to generate escape sequences). The escaping can be improved for printable runes outside basic ASCII (particularly for languages using non-latin stripts). Additionally, invalid UTF-8 can be improved. So we can experiment with the output format make this opt-in via a a new tracebacklabels GODEBUG var. Updates #23458 Updates #76349 Change-Id: I08e78a40c55839a809236fff593ef2090c13c036 Reviewed-on: https://go-review.googlesource.com/c/go/+/694119 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
2025-11-21runtime/pprof: remove hard-coded sleep in CPU profile readerNick Ripley
The CPU profiler reader goroutine has a hard-coded 100ms sleep between reads of the CPU profile sample buffer. This is done because waking up the CPU profile reader is not signal-safe on some platforms. As a consequence, stopping the profiler takes 200ms (one iteration to read the last samples and one to see the "eof"), and on many-core systems the reader does not wake up frequently enought to keep up with incoming data. This CL removes the sleep where it is safe to do so, following a suggestion by Austin Clements in the comments on CL 445375. We let the reader fully block, and wake up the reader when the buffer is over half-full. Fixes #63043 Updates #56029 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-arm64-longtest,gotip-linux-386-longtest Change-Id: I9f7e7e9918a4a6f16e80f6aaf33103126568a81f Reviewed-on: https://go-review.googlesource.com/c/go/+/610815 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
2025-11-12runtime,runtime/pprof: clean up goroutine leak profile writingVlad Saioc
Cleaned up goroutine leak profile extraction: - removed the acquisition of goroutineProfile semaphore - inlined the call to saveg when recording stacks instead of using doRecordGoroutineProfile, which had side-effects over goroutineProfile fields. Added regression tests for goroutine leak profiling frontend for binary and debug=1 profile formats. Added stress tests for concurrent goroutine and goroutine leak profile requests. Change-Id: I55c1bcef11e9a7fb7699b4c5a2353e594d3e7173 GitHub-Last-Rev: 5e9eb3b1d80c4d2d9b668a01f6b39a7b42f7bb45 GitHub-Pull-Request: golang/go#76045 Reviewed-on: https://go-review.googlesource.com/c/go/+/714580 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
2025-10-02runtime,net/http/pprof: goroutine leak detection by using the garbage collectorVlad Saioc
Proposal #74609 Change-Id: I97a754b128aac1bc5b7b9ab607fcd5bb390058c8 GitHub-Last-Rev: 60f2a192badf415112246de8bc6c0084085314f6 GitHub-Pull-Request: golang/go#74622 Reviewed-on: https://go-review.googlesource.com/c/go/+/688335 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: t hepudds <thepudds1460@gmail.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-05-13runtime/pprof: return errors from writing profilesSean Liao
Fixes #73107 Change-Id: I41f3e1bd1fdaca2f0e94151b2320bd569e258a51 Reviewed-on: https://go-review.googlesource.com/c/go/+/671576 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-05-07runtime: remove GODEBUG=runtimecontentionstacksRhys Hiltner
Go 1.22 promised to remove the setting in a future release once the semantics of runtime-internal lock contention matched that of sync.Mutex. That work is done, remove the setting. Previously reviewed as https://go.dev/cl/585639. For #66999 Change-Id: I9fe62558ba0ac12824874a0bb1b41efeb7c0853f Reviewed-on: https://go-review.googlesource.com/c/go/+/668995 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com> Reviewed-by: Carlos Amedee <carlos@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>
2024-11-16runtime/pprof: reduce label overheadFelix Geisendörfer
Switch labelMap from map[string]string to use LabelSet as a data structure. Optimize Labels() for the case where the keys are given in sorted order without duplicates. This is primarily motivated by reducing the overhead of distributed tracing systems that use pprof labels. We have encountered cases where users complained about the overhead relative to the rest of our distributed tracing library code. Additionally, we see this as an opportunity to free up hundreds of CPU cores across our fleet. A secondary motivation is eBPF profilers that try to access pprof labels. The current map[string]string requires them to implement Go map access in eBPF, which is non-trivial. With the enablement of swiss maps, this complexity is only increasing. The slice data structure introduced in this CL will greatly lower the implementation complexity for eBPF profilers in the future. But to be clear: This change does not imply that the pprof label mechanism is now a stable ABI. They are still an implementation detail and may change again in the future. goos: darwin goarch: arm64 pkg: runtime/pprof cpu: Apple M1 Max │ baseline.txt │ patch1.txt │ │ sec/op │ sec/op vs base │ Labels/set-one-10 153.50n ± 3% 75.00n ± 1% -51.14% (p=0.000 n=10) Labels/merge-one-10 187.8n ± 1% 128.8n ± 1% -31.42% (p=0.000 n=10) Labels/overwrite-one-10 193.1n ± 2% 102.0n ± 1% -47.18% (p=0.000 n=10) Labels/ordered/set-many-10 502.6n ± 4% 146.1n ± 2% -70.94% (p=0.000 n=10) Labels/ordered/merge-many-10 516.3n ± 2% 238.1n ± 1% -53.89% (p=0.000 n=10) Labels/ordered/overwrite-many-10 569.3n ± 4% 247.6n ± 2% -56.51% (p=0.000 n=10) Labels/unordered/set-many-10 488.9n ± 2% 308.3n ± 3% -36.94% (p=0.000 n=10) Labels/unordered/merge-many-10 523.6n ± 1% 258.5n ± 1% -50.64% (p=0.000 n=10) Labels/unordered/overwrite-many-10 571.4n ± 1% 412.1n ± 2% -27.89% (p=0.000 n=10) geomean 366.8n 186.9n -49.05% │ baseline.txt │ patch1b.txt │ │ B/op │ B/op vs base │ Labels/set-one-10 424.0 ± 0% 104.0 ± 0% -75.47% (p=0.000 n=10) Labels/merge-one-10 424.0 ± 0% 200.0 ± 0% -52.83% (p=0.000 n=10) Labels/overwrite-one-10 424.0 ± 0% 136.0 ± 0% -67.92% (p=0.000 n=10) Labels/ordered/set-many-10 1344.0 ± 0% 392.0 ± 0% -70.83% (p=0.000 n=10) Labels/ordered/merge-many-10 1184.0 ± 0% 712.0 ± 0% -39.86% (p=0.000 n=10) Labels/ordered/overwrite-many-10 1056.0 ± 0% 712.0 ± 0% -32.58% (p=0.000 n=10) Labels/unordered/set-many-10 1344.0 ± 0% 712.0 ± 0% -47.02% (p=0.000 n=10) Labels/unordered/merge-many-10 1184.0 ± 0% 712.0 ± 0% -39.86% (p=0.000 n=10) Labels/unordered/overwrite-many-10 1.031Ki ± 0% 1.008Ki ± 0% -2.27% (p=0.000 n=10) geomean 843.1 405.1 -51.95% │ baseline.txt │ patch1b.txt │ │ allocs/op │ allocs/op vs base │ Labels/set-one-10 5.000 ± 0% 3.000 ± 0% -40.00% (p=0.000 n=10) Labels/merge-one-10 5.000 ± 0% 5.000 ± 0% ~ (p=1.000 n=10) ¹ Labels/overwrite-one-10 5.000 ± 0% 4.000 ± 0% -20.00% (p=0.000 n=10) Labels/ordered/set-many-10 8.000 ± 0% 3.000 ± 0% -62.50% (p=0.000 n=10) Labels/ordered/merge-many-10 8.000 ± 0% 5.000 ± 0% -37.50% (p=0.000 n=10) Labels/ordered/overwrite-many-10 7.000 ± 0% 4.000 ± 0% -42.86% (p=0.000 n=10) Labels/unordered/set-many-10 8.000 ± 0% 4.000 ± 0% -50.00% (p=0.000 n=10) Labels/unordered/merge-many-10 8.000 ± 0% 5.000 ± 0% -37.50% (p=0.000 n=10) Labels/unordered/overwrite-many-10 7.000 ± 0% 5.000 ± 0% -28.57% (p=0.000 n=10) geomean 6.640 4.143 -37.60% ¹ all samples are equal Change-Id: Ie68e960a25c2d97bcfb6239dc481832fa8a39754 Reviewed-on: https://go-review.googlesource.com/c/go/+/574516 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2024-11-13runtime/pprof: note different between go test -memprofile and WriteHeapProfileSean Liao
Fixes #65328 Change-Id: I11242be93a95e117a6758ac037e143c3b38aa71c Reviewed-on: https://go-review.googlesource.com/c/go/+/597980 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2024-07-17runtime: avoid multiple records with identical stacks from MutexProfileNick Ripley
When using frame pointer unwinding, we defer frame skipping and inline expansion for call stacks until profile reporting time. We can end up with records which have different stacks if no frames are skipped, but identical stacks once skipping is taken into account. Returning multiple records with the same stack (but different values) has broken programs which rely on the records already being fully aggregated by call stack when returned from runtime.MutexProfile. This CL addresses the problem by handling skipping at recording time. We do full inline expansion to correctly skip the desired number of frames when recording the call stack, and then handle the rest of inline expansion when reporting the profile. The regression test in this CL is adapted from the reproducer in https://github.com/grafana/pyroscope-go/issues/103, authored by Tolya Korniltsev. Fixes #67548 This reapplies CL 595966. The original version of this CL introduced a bounds error in MutexProfile and failed to correctly expand inlined frames from that call. This CL applies the original CL, fixing the bounds error and adding a test for the output of MutexProfile to ensure the frames are expanded properly. Change-Id: I5ef8aafb9f88152a704034065c0742ba767c4dbb Reviewed-on: https://go-review.googlesource.com/c/go/+/598515 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-07-15Revert "runtime: avoid multiple records with identical stacks from MutexProfile"Cherry Mui
This reverts CL 595966. Reason for revert: This CL contains a bug. See the comment in https://go-review.googlesource.com/c/go/+/595966/8#message-57f4c1f9570b5fe912e06f4ae3b52817962533c0 Change-Id: I48030907ded173ae20a8965bf1b41a713dd06059 Reviewed-on: https://go-review.googlesource.com/c/go/+/598219 Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2024-07-09runtime: avoid multiple records with identical stacks from MutexProfileNick Ripley
When using frame pointer unwinding, we defer frame skipping and inline expansion for call stacks until profile reporting time. We can end up with records which have different stacks if no frames are skipped, but identical stacks once skipping is taken into account. Returning multiple records with the same stack (but different values) has broken programs which rely on the records already being fully aggregated by call stack when returned from runtime.MutexProfile. This CL addresses the problem by handling skipping at recording time. We do full inline expansion to correctly skip the desired number of frames when recording the call stack, and then handle the rest of inline expansion when reporting the profile. The regression test in this CL is adapted from the reproducer in https://github.com/grafana/pyroscope-go/issues/103, authored by Tolya Korniltsev. Fixes #67548 Co-Authored-By: Tolya Korniltsev <korniltsev.anatoly@gmail.com> Change-Id: I6a42ce612377f235b2c8c0cec9ba8e9331224b84 Reviewed-on: https://go-review.googlesource.com/c/go/+/595966 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Carlos Amedee <carlos@golang.org> Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
2024-07-03cmd/link: don't disable memory profiling when pprof.WriteHeapProfile is usedCherry Mui
We have an optimization that if the memory profile is not consumed anywhere, we set the memory profiling rate to 0 to disable the "background" low-rate profiling. We detect whether the memory profile is used by checking whether the runtime.MemProfile function is reachable at link time. Previously, all APIs that access the memory profile go through runtime.MemProfile. But the code was refactored in CL 572396, and now the legacy entry point WriteHeapProfile uses pprof_memProfileInternal without going through runtime.MemProfile. In fact, even with the recommended runtime/pprof.Profile API (pprof.Lookup or pprof.Profiles), runtime.MemProfile is only (happen to be) reachable through countHeap. Change the linker to check runtime.memProfileInternal instead, which is on all code paths that retrieve the memory profile. Add a test case for WriteHeapProfile, so we cover all entry points. Fixes #68136. Change-Id: I075c8d45c95c81825a1822f032e23107aea4303c Reviewed-on: https://go-review.googlesource.com/c/go/+/596538 Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-30Revert "runtime: remove GODEBUG=runtimecontentionstacks"Rhys Hiltner
This reverts commit 87e930f7289136fad1310d4b63dd4127e409bac5 (CL 585639) Reason for revert: This is part of a patch series that changed the handling of contended lock2/unlock2 calls, reducing the maximum throughput of contended runtime.mutex values, and causing a performance regression on applications where that is (or became) the bottleneck. Updates #66999 Updates #67585 Change-Id: I1e286d2a16d16e4af202cd5dc04b2d9c4ee71b32 Reviewed-on: https://go-review.googlesource.com/c/go/+/589097 Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
2024-05-29all: document legacy //go:linkname for modules with ≥100 dependentsRuss Cox
For #67401. Change-Id: I015408a3f437c1733d97160ef2fb5da6d4efcc5c Reviewed-on: https://go-review.googlesource.com/c/go/+/587598 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Russ Cox <rsc@golang.org>
2024-05-23all: change from sort functions to slices functions where feasibleIan Lance Taylor
Doing this because the slices functions are slightly faster and slightly easier to use. It also removes one dependency layer. This CL does not change packages that are used during bootstrap, as the bootstrap compiler does not have the required slices functions. It does not change the go/scanner package because the ErrorList Len, Swap, and Less methods are part of the Go 1 API. Change-Id: If52899be791c829198e11d2408727720b91ebe8a Reviewed-on: https://go-review.googlesource.com/c/go/+/587655 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> Commit-Queue: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2024-05-21runtime: remove GODEBUG=runtimecontentionstacksRhys Hiltner
Go 1.22 promised to remove the setting in a future release once the semantics of runtime-internal lock contention matched that of sync.Mutex. That work is done, remove the setting. For #66999 Change-Id: I3c4894148385adf2756d8754e44d7317305ad758 Reviewed-on: https://go-review.googlesource.com/c/go/+/585639 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2024-05-21runtime: increase profiling stack depth to 128Felix Geisendörfer
The current stack depth limit for alloc, mutex, block, threadcreate and goroutine profiles of 32 frequently leads to truncated stack traces in production applications. Increase the limit to 128 which is the same size used by the execution tracer. Create internal/profilerecord to define variants of the runtime's StackRecord, MemProfileRecord and BlockProfileRecord types that can hold arbitrarily big stack traces. Implement internal profiling APIs based on these new types and use them for creating protobuf profiles and to act as shims for the public profiling APIs using the old types. This will lead to an increase in memory usage for applications that use the impacted profile types and have stack traces exceeding the current limit of 32. Those applications will also experience a slight increase in CPU usage, but this will hopefully soon be mitigated via CL 540476 and 533258 which introduce frame pointer unwinding for the relevant profile types. For #43669. Change-Id: Ie53762e65d0f6295f5d4c7d3c87172d5a052164e Reviewed-on: https://go-review.googlesource.com/c/go/+/572396 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-02-20runtime/pprof: update outdated google/pprof linkhi-rustin
Google/pprof changed the master branch to main, so it might be better to update it to the latest. Change-Id: Id29aca80a9a83a9c10da215180ad65816bc88936 GitHub-Last-Rev: 0023c28dc0d84a2529e24c694acfed7a363d2d0b GitHub-Pull-Request: golang/go#65792 Reviewed-on: https://go-review.googlesource.com/c/go/+/565177 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2024-01-30runtime: avoid new linkname for goroutine profilesMichael Pratt
CL 464349 added a new linkname to provide gcount to runtime/pprof to avoid a STW when estimating the goroutine profile allocation size. However, adding a linkname here isn't necessary for a few reasons: 1. We already export gcount via NumGoroutines. I completely forgot about this during review. 2. aktau suggested that goroutineProfileWithLabelsConcurrent return gcount as a fast path estimate when the input is empty. The second point keeps the code cleaner overall, so I've done that. For #54014. Change-Id: I6cb0811a769c805e269b55774cdd43509854078e Reviewed-on: https://go-review.googlesource.com/c/go/+/559515 Auto-Submit: Michael Pratt <mpratt@google.com> Auto-Submit: Nicolas Hillegeer <aktau@google.com> Reviewed-by: Nicolas Hillegeer <aktau@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-30runtime: reduce one STW when obtaining goroutine configuration fileJun10ng
Fixes #54014 Change-Id: If4ee2752008729e1ed4b767cfda52effdcec4959 GitHub-Last-Rev: 5ce300bf5128f842604d85d5f8749027c8e091c2 GitHub-Pull-Request: golang/go#58239 Reviewed-on: https://go-review.googlesource.com/c/go/+/464349 Reviewed-by: qiulaidongfeng <2645477756@qq.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: qiulaidongfeng <2645477756@qq.com> 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>
2023-12-30all: replace outdated linkscui fliter
Change-Id: I7156e7858e8f06459818e03729c644d64e04d43c Reviewed-on: https://go-review.googlesource.com/c/go/+/549356 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: shuang cui <imcusg@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-12-06runtime/pprof: add section headers to Profile docMichael Pratt
Adding explicit section headers makes it cleaner to split the profile descriptions into multiple paragraphs, as there is now an explicit transition from discussion of one profile type to the next. For #14689. Change-Id: Ifcff918367e91a165ee5f74423be3935b421972b Reviewed-on: https://go-review.googlesource.com/c/go/+/547955 Reviewed-by: Rhys Hiltner <rhys@justin.tv> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2023-12-06runtime/pprof: document block and mutex profilesMichael Pratt
Amazingly, we seem to have nearly no in-tree documentation on the semantics of block and mutex profiles. Add brief summaries, including the new behavior from CL 506415 and CL 544195. For #14689. For #44920. For #57071. For #61015. Change-Id: I1a6edce7c434fcb43f17c83eb362b1f9d1a32df1 Reviewed-on: https://go-review.googlesource.com/c/go/+/547057 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Rhys Hiltner <rhys@justin.tv> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-11-08runtime: add available godoc linkcui fliter
Change-Id: Ifb4844efddcb0369b0302eeab72394eeaf5c8072 Reviewed-on: https://go-review.googlesource.com/c/go/+/540022 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: shuang cui <imcusg@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2022-11-18all: add missing periods in commentscui fliter
Change-Id: I69065f8adf101fdb28682c55997f503013a50e29 Reviewed-on: https://go-review.googlesource.com/c/go/+/449757 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Joedian Reid <joedian@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Joedian Reid <joedian@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-11-15runtime/pprof: scale mutex profile samples when they are recordedNick Ripley
Samples in the mutex profile have their count and duration scaled according to the probability they were sampled. This is done when the profile is actually requested. The adjustment is done using to the current configured sampling rate. However, if the sample rate is changed after a specific sample is recorded, then the sample will be scaled incorrectly. In particular, if the sampling rate is changed to 0, all of the samples in the encoded profile will have 0 count and duration. This means the profile will be "empty", even if it should have had samples. This CL scales the samples in the profile when they are recorded, rather than when the profile is requested. This matches what is currently done for the block profile. With this change, neither the block profile nor mutex profile are scaled when they are encoded, so the logic for scaling the samples can be removed. Change-Id: If228cf39284385aa8fb9a2d62492d839e02f027f Reviewed-on: https://go-review.googlesource.com/c/go/+/443056 Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Joedian Reid <joedian@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-09-23runtime/pprof: force use of 4-column profiles in pprof memprofile outputRuss Cox
Pprof's converter from legacy text format to protobuf format assumes that if the alloc and inuse stats are equal, then what's really going on is that the program makes no distinction, and it reads them as a two-column profile: objects and bytes. Most of the time, some sampled object has been freed, and alloc != inuse. In that case, pprof reads the profile as a four-column profile, with alloc_objects, alloc_bytes, inuse_objects, inuse_bytes. The 2-column form causes problems in a few ways. One is that if you are reading the proto form and expect samples with the 4-column names, they're not there. Another is that pprof's profile merger insists on having the same number of columns and same names. This means that pprof *.memprofile works most of the time but fails if one of the memory profiles hit the unlikely condition that alloc == inuse, since now its converted form differs from the others. Most programs should simply not be using this output form at all, but cmd/compile and cmd/link still do, because x/tools/cmd/compilebench reads some extra values from the text form that we have not yet added to the proto form. For the programs still writing this form, the easiest way to avoid the column collapse issues is to ensure that the header never reports alloc == inuse. The actual values in the header are ignored by pprof now, except for the equality check (they should sum to the other values in the file, so they are technically redundant). Because the actual values are not used except for the equality check, we could hard-code different values like 0 and 1, but just in case, to break as little as possible, this CL only adjusts the values when they would otherwise be equal. In that case it adds 1 to allocBytes. For most profiles, where alloc != inuse already, there is no effect at all. Change-Id: Ia563e402573d0f6eb81ae496645db27c08f9fe31 Reviewed-on: https://go-review.googlesource.com/c/go/+/432758 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
2022-09-08runtime/pprof: use strings.Buildercuiweixie
Change-Id: I0407d96e2ba1376cc33fe91b52b6a8d7e81f59ae Reviewed-on: https://go-review.googlesource.com/c/go/+/428277 Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-04-11all: gofmt main repoRuss Cox
[This CL is part of a sequence implementing the proposal #51082. The design doc is at https://go.dev/s/godocfmt-design.] Run the updated gofmt, which reformats doc comments, on the main repository. Vendored files are excluded. For #51082. Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407 Reviewed-on: https://go-review.googlesource.com/c/go/+/384268 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2022-04-01all: remove trailing blank doc comment linesRuss Cox
A future change to gofmt will rewrite // Doc comment. // func f() to // Doc comment. func f() Apply that change preemptively to all doc comments. For #51082. Change-Id: I4023e16cfb0729b64a8590f071cd92f17343081d Reviewed-on: https://go-review.googlesource.com/c/go/+/384259 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-13all: gofmt -w -r 'interface{} -> any' srcRuss Cox
And then revert the bootstrap cmd directories and certain testdata. And adjust tests as needed. Not reverting the changes in std that are bootstrapped, because some of those changes would appear in API docs, and we want to use any consistently. Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories when preparing the bootstrap copy. A few files changed as a result of running gofmt -w not because of interface{} -> any but because they hadn't been updated for the new //go:build lines. Fixes #49884. Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09 Reviewed-on: https://go-review.googlesource.com/c/go/+/368254 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-05-24[dev.typeparams] runtime/pprof: replace funcPC with ↵Cherry Mui
internal/abi.FuncPCABIInternal All funcPC references are ABIInternal functions. Replace with the intrinsics. Change-Id: I2266bb6d2b713eb63b6a09846e9f9c423cab6e9b Reviewed-on: https://go-review.googlesource.com/c/go/+/322349 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-03-18runtime/pprof: move common code to writeProfileInternal functionElvina Yakubova
This patch provides changes according to TODO. Since writeMutex and writeBlock functions have a lot of code in common, it is better to move this code to one function. Change-Id: I81aaad067b0cb1647824909f3b5f6861add3a7ba Reviewed-on: https://go-review.googlesource.com/c/go/+/280152 Reviewed-by: Cherry Zhang <cherryyz@google.com> Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
2020-04-22runtime/pprof: plumb labels for goroutine profilesDavid Finkel
Goroutines are directly associated with labels. It's relatively easy to plumb those through without creating goroutine-locals in the wild. This is accomplished by splitting out most of the code from the public `runtime.GoroutineProfile` into a new unexported `runtime.goroutineProfileWithLabels`, which then has a thin wrapper linked into the `runtime/pprof` package as `runtime_goroutineProfileWithLabels`. (mirroring the way labels get associated with the `g` for a goroutine in the first place) Per-#6104, OS-thread creation profiles are a bit useless, as `M`s tend to be created be created by a background goroutine. As such, I decided not to add support for capturing the labels at `M`-creation-time, since the stack-traces seem to always come out `nil` for my simple test binaries. This change currently provides labels for debug=0 and debug=1, as debug=2 is currently entirely generated by the runtime package and I don't see a clean way of getting the `labelMap` type handled properly within the `runtime` package. Update the comment added in cl/131275 to mention goroutine support for labels. Updates #23458 Change-Id: Ia4b558893d7d10156b77121cd9b70c4ccd9e1889 Reviewed-on: https://go-review.googlesource.com/c/go/+/189318 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2020-04-21Revert "runtime/pprof: speed up CPU profiling shutdown"Josh Bleecher Snyder
This reverts commit 1f0738c1577a55a6b7229b821ddfe762b84771d0. Reason for revert: This May have caused issue 38567. Change-Id: I2afa6a9d42cb29cfad09e706fb465c57e3774abd Reviewed-on: https://go-review.googlesource.com/c/go/+/229301 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2020-04-20runtime/pprof: speed up CPU profiling shutdownJosh Bleecher Snyder
The core CPU profiling loop contains a 100ms sleep. This is important to reduce overhead. However, it means that it takes 200ms to shutting down a program with CPU profiling enabled. When trying to collect many samples by running a short-lived program many times, this adds up. This change cuts the shutdown penalty in half by skipping the sleep whenever possible. Change-Id: Ic3177f8e1a2d331fe1a1ecd7c8c06f50beb42535 Reviewed-on: https://go-review.googlesource.com/c/go/+/228886 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2020-03-17runtime/pprof: export max rss when saving memory profiles.Jeremy Faller
NB: Adds syscall to deps on runtime/pprof. Change-Id: I5dd14c2b25eb9c3c446832f5818de45fafd48a27 Reviewed-on: https://go-review.googlesource.com/c/go/+/183844 Run-TryBot: Jeremy Faller <jeremy@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2020-03-11runtime/pprof: document that debug=0 emits protoTamir Duberstein
Updates #16093. Change-Id: I629b3d44d6b2083f5e62701cc0c23fe2362502d4 Reviewed-on: https://go-review.googlesource.com/c/go/+/222676 Reviewed-by: Michael Matloob <matloob@golang.org>
2019-11-08runtime/pprof: correct inlined function location encoding for non-CPU profilesHana (Hyang-Ah) Kim
Change-Id: Id270a3477bf1a581755c4311eb12f990aa2260b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/205097 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-11-05runtime/pprof: update example comment to check error on CloseIan Lance Taylor
Programs should always check the error return of Close for a file opened for writing. Update the example code in the comment to mention this. Change-Id: I2ff6866ff1fe23b47c54268ac8e182210cc876c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/202137 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-08-22runtime/pprof: fix resource leak in documentationRoland Illig
Fixes #26970 Change-Id: I0f2695434a53550cf84f702e9d8d02a37448d396 Reviewed-on: https://go-review.googlesource.com/129195 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-05-21runtime/pprof: update stale link in documentationAlberto Donizetti
Fixes #25477 Change-Id: I6f724bb855cfffa21de090c1fcb04d58d7cdd9d8 Reviewed-on: https://go-review.googlesource.com/113839 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-04-24runtime/pprof: introduce "allocs" profileHana (Hyang-Ah) Kim
The Go's heap profile contains four kinds of samples (inuse_space, inuse_objects, alloc_space, and alloc_objects). The pprof tool by default chooses the inuse_space (the bytes of live, in-use objects). When analyzing the current memory usage the choice of inuse_space as the default may be useful, but in some cases, users are more interested in analyzing the total allocation statistics throughout the program execution. For example, when we analyze the memory profile from benchmark or program test run, we are more likely interested in the whole allocation history than the live heap snapshot at the end of the test or benchmark. The pprof tool provides flags to control which sample type to be used for analysis. However, it is one of the less-known features of pprof and we believe it's better to choose the right type of samples as the default when producing the profile. This CL introduces a new type of profile, "allocs", which is the same as the "heap" profile but marks the alloc_space as the default type unlike heap profiles that use inuse_space as the default type. 'go test -memprofile=...' command is changed to use the new "allocs" profile type instead of the traditional "heap" profile. Fixes #24443 Change-Id: I012dd4b6dcacd45644d7345509936b8380b6fbd9 Reviewed-on: https://go-review.googlesource.com/102696 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Russ Cox <rsc@golang.org>
2018-01-24runtime/pprof: scale mutex profile with sampling rateHana Kim
pprof expects the samples are scaled and reflects unsampled numbers. The legacy profile parser uses the sampling period in the output and multiplies all values with the period. https://github.com/google/pprof/blob/0138a3cd6dad6f94495ba0b5c3a5c124f04ae011/profile/legacy_profile.go#L815 Apply the same scaling when we output the mutex profile in the pprof proto format. Block profile shares the same code, but how to infer unsampled values is unclear. Legacy profile parser doesn't do anything special so we do nothing for block profile here. Tested by checking the profiles reported with debug=0 (proto format) are similar to the profiles computed from legacy format profile when the profile rate is a non-trivial number (e.g. 2) manually. Change-Id: Iaa33f92051deed67d8be43ddffc7c1016db566ca Reviewed-on: https://go-review.googlesource.com/89295 Reviewed-by: Peter Weinberger <pjw@google.com>
2017-12-01runtime/pprof: read memstats earlier in profile handlerRuss Cox
Reading the mem stats before our own allocations avoids cluttering memory stats with our recent garbage. Fixes #20565. Change-Id: I3b0046c8300dca83cea24013ffebc32b2ae7f742 Reviewed-on: https://go-review.googlesource.com/80739 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-11-18runtime/pprof: fix doc typoDavor Kapsa
Change-Id: I6e814182d89c3e7ff184141af097af0afb844d00 Reviewed-on: https://go-review.googlesource.com/78620 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 05:53:21 +0000