Skip to content

Commit e914671

Browse files
prattmicgopherbot
authored andcommitted
runtime/pprof: add section headers to Profile doc
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 <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Michael Pratt <[email protected]>
1 parent 6ee2719 commit e914671

File tree

1 file changed

+36
-21
lines changed

1 file changed

+36
-21
lines changed

src/runtime/pprof/pprof.go

Lines changed: 36 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -109,6 +109,12 @@ import (
109109
// These predefined profiles maintain themselves and panic on an explicit
110110
// [Profile.Add] or [Profile.Remove] method call.
111111
//
112+
// The CPU profile is not available as a Profile. It has a special API,
113+
// the [StartCPUProfile] and [StopCPUProfile] functions, because it streams
114+
// output to a writer during profiling.
115+
//
116+
// # Heap profile
117+
//
112118
// The heap profile reports statistics as of the most recently completed
113119
// garbage collection; it elides more recent allocation to avoid skewing
114120
// the profile away from live data and toward garbage.
@@ -122,38 +128,47 @@ import (
122128
// flags select which to display, defaulting to -inuse_space (live objects,
123129
// scaled by size).
124130
//
131+
// # Allocs profile
132+
//
125133
// The allocs profile is the same as the heap profile but changes the default
126134
// pprof display to -alloc_space, the total number of bytes allocated since
127135
// the program began (including garbage-collected bytes).
128136
//
137+
// # Block profile
138+
//
129139
// The block profile tracks time spent blocked on synchronization primitives,
130140
// such as [sync.Mutex], [sync.RWMutex], [sync.WaitGroup], [sync.Cond], and
131-
// channel send/receive/select. Stack traces correspond to the location that
132-
// blocked (for example, [sync.Mutex.Lock]). Sample values correspond to
133-
// cumulative time spent blocked at that stack trace, subject to time-based
134-
// sampling specified by [runtime.SetBlockProfileRate].
141+
// channel send/receive/select.
142+
//
143+
// Stack traces correspond to the location that blocked (for example,
144+
// [sync.Mutex.Lock]).
145+
//
146+
// Sample values correspond to cumulative time spent blocked at that stack
147+
// trace, subject to time-based sampling specified by
148+
// [runtime.SetBlockProfileRate].
149+
//
150+
// # Mutex profile
135151
//
136152
// The mutex profile tracks contention on mutexes, such as [sync.Mutex],
137-
// [sync.RWMutex], and runtime-internal locks. Stack traces correspond to the
138-
// end of the critical section causing contention. For example, a lock held for
139-
// a long time while other goroutines are waiting to acquire the lock will
140-
// report contention when the lock is finally unlocked (that is, at
141-
// [sync.Mutex.Unlock]). Sample values correspond to the approximate cumulative
142-
// time other goroutines spent blocked waiting for the lock, subject to
143-
// event-based sampling specified by [runtime.SetMutexProfileFraction]. For
144-
// example, if a caller holds a lock for 1s while 5 other goroutines are
145-
// waiting for the entire second to acquire the lock, its unlock call stack
146-
// will report 5s of contention.
147-
//
148-
// In the mutex profile, runtime-internal locks are always reported at the
149-
// location "runtime._LostContendedRuntimeLock". More detailed stack traces for
153+
// [sync.RWMutex], and runtime-internal locks.
154+
//
155+
// Stack traces correspond to the end of the critical section causing
156+
// contention. For example, a lock held for a long time while other goroutines
157+
// are waiting to acquire the lock will report contention when the lock is
158+
// finally unlocked (that is, at [sync.Mutex.Unlock]).
159+
//
160+
// Sample values correspond to the approximate cumulative time other goroutines
161+
// spent blocked waiting for the lock, subject to event-based sampling
162+
// specified by [runtime.SetMutexProfileFraction]. For example, if a caller
163+
// holds a lock for 1s while 5 other goroutines are waiting for the entire
164+
// second to acquire the lock, its unlock call stack will report 5s of
165+
// contention.
166+
//
167+
// Runtime-internal locks are always reported at the location
168+
// "runtime._LostContendedRuntimeLock". More detailed stack traces for
150169
// runtime-internal locks can be obtained by setting
151170
// `GODEBUG=runtimecontentionstacks=1` (see package [runtime] docs for
152171
// caveats).
153-
//
154-
// The CPU profile is not available as a Profile. It has a special API,
155-
// the [StartCPUProfile] and [StopCPUProfile] functions, because it streams
156-
// output to a writer during profiling.
157172
type Profile struct {
158173
name string
159174
mu sync.Mutex

0 commit comments

Comments
 (0)