chore(check_golang_profiler_changes): acknowledge new golang profiler changes

[github-actions]

This PR is created by godeltaprof/compat/cmd/check_golang_profiler_changes/main.go to notify src/runtime/mprof.go or src/runtime/pprof in golang are updated.
Please take look at the golang commits and update godeltaprof accordingly if needed.
Merge the PR to acknowledge golang runtime changes and state no further actions needed for godeltaprof.

src/runtime/mprof.go
last known 2141315251da47745c8f649c01e598a19bd68897
current 9114c51521c641ff6c33648da03774dc3eb86b79

commit 9114c51521c641ff6c33648da03774dc3eb86b79
Author: Rhys Hiltner <[email protected]>
Date:   Wed May 29 16:43:38 2024 +0000

    Revert "runtime: prepare for extensions to waiting M list"
    
    This reverts commit be0b569caa0eab1a7f30edf64e550bbf5f6ff235 (CL 585635).
    
    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: I7843ccaecbd273b7ceacfa0f420dd993b4b15a0a
    Reviewed-on: https://go-review.googlesource.com/c/go/+/589117
    Auto-Submit: Rhys Hiltner <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Than McIntosh <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

commit afbbc2894b4af076d7f171fd6e83541d35b7b5a3
Author: Rhys Hiltner <[email protected]>
Date:   Wed May 29 16:42:23 2024 +0000

    Revert "runtime: double-link list of waiting Ms"
    
    This reverts commit d881ed6384ae58154d99682f1e20160c64e7c3c2 (CL 585637).
    
    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: I70d8d0b74f73be95c43d664f584e8d98519aba26
    Reviewed-on: https://go-review.googlesource.com/c/go/+/589116
    Auto-Submit: Rhys Hiltner <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Than McIntosh <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

commit 5dead59add1f11e98de155860aa86175e893ac01
Author: Rhys Hiltner <[email protected]>
Date:   Wed May 29 16:41:51 2024 +0000

    Revert "runtime: profile mutex contention during unlock"
    
    This reverts commit ba1c5b2c4573e10f3b5f0e0f25a27f17fba67eb0 (CL 585638).
    
    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: Ibeec5d8deb17e87966cf352fefc7efe2267839d6
    Reviewed-on: https://go-review.googlesource.com/c/go/+/589115
    Auto-Submit: Rhys Hiltner <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>
    Reviewed-by: Than McIntosh <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>

commit ca7d300509626e2071f3f5babc2e9c121d806fec
Author: Rhys Hiltner <[email protected]>
Date:   Wed May 29 16:41:10 2024 +0000

    Revert "runtime: remove GODEBUG=runtimecontentionstacks"
    
    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 <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>

commit 1be701a344d1f1819dc08d78259684de1da6f923
Author: Rhys Hiltner <[email protected]>
Date:   Wed May 29 16:36:36 2024 +0000

    Revert "runtime: split mutex profile clocks"
    
    This reverts commit 8ab131fb1256a4a795c610e145c022e22e2d1567 (CL 586796)
    
    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: I54711691e86e072081482102019d168292b5150a
    Reviewed-on: https://go-review.googlesource.com/c/go/+/589095
    Reviewed-by: Michael Pratt <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Than McIntosh <[email protected]>

commit 8ab131fb1256a4a795c610e145c022e22e2d1567
Author: Rhys Hiltner <[email protected]>
Date:   Tue May 21 23:17:13 2024 -0700

    runtime: split mutex profile clocks
    
    Mutex contention measurements work with two clocks: nanotime for use in
    runtime/metrics, and cputicks for the runtime/pprof profile. They're
    subject to different sampling rates: the runtime/metrics view is always
    enabled, but the profile is adjustable and is turned off by default.
    They have different levels of overhead: it can take as little as one
    instruction to read cputicks while nanotime calls are more elaborate
    (although some platforms implement cputicks as a nanotime call). The use
    of the timestamps is also different: the profile's view needs to attach
    the delay in some Ms' lock2 calls to another M's unlock2 call stack, but
    the metric's view is only an int64.
    
    Treat them differently. Don't bother threading the nanotime clock
    through to the unlock2 call, measure and report it directly within
    lock2. Sample nanotime at a constant gTrackingPeriod.
    
    Don't consult any clocks unless the mutex is actually contended.
    
    Continue liberal use of cputicks for now.
    
    For #66999
    
    Change-Id: I1c2085ea0e695bfa90c30fadedc99ced9eb1f69e
    Reviewed-on: https://go-review.googlesource.com/c/go/+/586796
    TryBot-Result: Gopher Robot <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Run-TryBot: Rhys Hiltner <[email protected]>
    Reviewed-by: Carlos Amedee <[email protected]>

commit 87e930f7289136fad1310d4b63dd4127e409bac5
Author: Rhys Hiltner <[email protected]>
Date:   Tue May 14 14:44:37 2024 -0700

    runtime: remove GODEBUG=runtimecontentionstacks
    
    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 <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

commit ba1c5b2c4573e10f3b5f0e0f25a27f17fba67eb0
Author: Rhys Hiltner <[email protected]>
Date:   Tue May 14 12:32:14 2024 -0700

    runtime: profile mutex contention during unlock
    
    When an M's use of a lock causes delays in other Ms, capture the stack
    of the unlock call that caused the delay. This makes the meaning of the
    mutex profile for runtime-internal mutexes match the behavior for
    sync.Mutex: the profile points to the end of the critical section that
    is responsible for delaying other work.
    
    Fixes #66999
    
    Change-Id: I4abc4a1df00a48765d29c07776481a1cbd539ff8
    Reviewed-on: https://go-review.googlesource.com/c/go/+/585638
    Auto-Submit: Rhys Hiltner <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Carlos Amedee <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

commit d881ed6384ae58154d99682f1e20160c64e7c3c2
Author: Rhys Hiltner <[email protected]>
Date:   Mon May 13 13:00:52 2024 -0700

    runtime: double-link list of waiting Ms
    
    When an M unlocks a contended mutex, it needs to consult a list of the
    Ms that had to wait during its critical section. This allows the M to
    attribute the appropriate amount of blame to the unlocking call stack.
    
    Mirroring the implementation for users' sync.Mutex contention (via
    sudog), we can (in a future commit) use the time that the head and tail
    of the wait list started waiting, and the number of waiters, to estimate
    the sum of the Ms' delays.
    
    When an M acquires the mutex, it needs to remove itself from the list of
    waiters. Since the futex-based lock implementation leaves the OS in
    control of the order of M wakeups, we need to be prepared for quickly
    (constant time) removing any M from the list.
    
    First, have each M add itself to a singly-linked wait list when it finds
    that its lock call will need to sleep. This case is safe against
    live-lock, since any delay to one M adding itself to the list would be
    due to another M making durable progress.
    
    Second, have the M that holds the lock (either right before releasing,
    or right after acquiring) update metadata on the list of waiting Ms to
    double-link the list and maintain a tail pointer and waiter count. That
    work is amortized-constant: we'll avoid contended locks becoming
    proportionally more contended and undergoing performance collapse.
    
    For #66999
    
    Change-Id: If75cdea915afb59ccec47294e0b52c466aac8736
    Reviewed-on: https://go-review.googlesource.com/c/go/+/585637
    Reviewed-by: Dmitri Shuralyov <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>

commit be0b569caa0eab1a7f30edf64e550bbf5f6ff235
Author: Rhys Hiltner <[email protected]>
Date:   Mon May 13 12:23:58 2024 -0700

    runtime: prepare for extensions to waiting M list
    
    Move the nextwaitm field into a small struct, in preparation for
    additional metadata to track how long Ms need to wait for locks.
    
    For #66999
    
    Change-Id: Ib40e43c15cde22f7e35922641107973d99439ecd
    Reviewed-on: https://go-review.googlesource.com/c/go/+/585635
    Reviewed-by: Michael Pratt <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>
    Reviewed-by: Dmitri Shuralyov <[email protected]>

commit 66cc2b7ca760d62294584d6680df65892cf7a8cf
Author: Felix Geisendörfer <[email protected]>
Date:   Sat Apr 27 13:41:05 2024 +0200

    runtime: make profstackdepth a GODEBUG option
    
    Allow users to decrease the profiling stack depth back to 32 in case
    they experience any problems with the new default of 128.
    
    Users may also use this option to increase the depth up to 1024.
    
    Change-Id: Ieaab2513024915a223239278dd97a6e161dde1cf
    Reviewed-on: https://go-review.googlesource.com/c/go/+/581917
    Reviewed-by: Austin Clements <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Michael Knyszek <[email protected]>

commit 1b9dc3e178be578cf1d8c06fe371283a58bdd93f
Author: Felix Geisendörfer <[email protected]>
Date:   Fri May 17 15:07:07 2024 +0200

    runtime: increase profiling stack depth to 128
    
    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 <[email protected]>
    Reviewed-by: Austin Clements <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>

commit 47187a4f4f226c4b9e0e920c5ad1ec9ce83bdc35
Author: Felix Geisendörfer <[email protected]>
Date:   Sun May 19 15:21:53 2024 +0200

    runtime: fix profile stack trace depth regression
    
    Previously it was possible for mutex and block profile stack traces to
    contain up to 32 frames in Stack0 or the resulting pprof profiles.
    CL 533258 changed this behavior by using some of the space to
    record skipped frames that are discarded when performing delayed inline
    expansion. This has lowered the effective maximum stack size from 32 to
    27 (the max skip value is 5), which can be seen as a small regression.
    
    Add TestProfilerStackDepth to demonstrate the issue and protect all
    profile types from similar regressions in the future. Fix the issue by
    increasing the internal maxStack limit to take the maxSkip value into
    account. Assert that the maxSkip value is never exceeded when recording
    mutex and block profile stack traces.
    
    Three alternative solutions to the problem were considered and
    discarded:
    
    1) Revert CL 533258 and give up on frame pointer unwinding. This seems
       unappealing as we would lose the performance benefits of frame
       pointer unwinding.
    2) Discard skipped frames when recording the initial stack trace. This
       would require eager inline expansion for up to maxSkip frames and
       partially negate the performance benefits of frame pointer
       unwinding.
    3) Accept and document the new behavior. This would simplify the
       implementation, but seems more confusing from a user perspective. It
       also complicates the creation of test cases that make assertions
       about the maximum profiling stack depth.
    
    The execution tracer still has the same issue due to CL 463835. This
    should be addressed in a follow-up CL.
    
    Co-authored-by: Nick Ripley <[email protected]>
    Change-Id: Ibf4dbf08a5166c9cb32470068c69f58bc5f98d2c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/586657
    Reviewed-by: Austin Clements <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>

commit f4494522dc067bc930dc73b91e3ef931ce4583da
Author: Nick Ripley <[email protected]>
Date:   Fri Oct 6 13:02:40 2023 -0400

    runtime: use frame pointer unwinding for block and mutex profilers
    
    Use frame pointer unwinding, where supported, to collect call stacks for
    the block, and mutex profilers. This method of collecting call stacks is
    typically an order of magnitude faster than callers/tracebackPCs. The
    marginal benefit for these profile types is likely small compared to
    using frame pointer unwinding for the execution tracer. However, the
    block profiler can have noticeable overhead unless the sampling rate is
    very high. Additionally, using frame pointer unwinding in more places
    helps ensure more testing/support, which benefits systems like the
    execution tracer which rely on frame pointer unwinding to be practical
    to use.
    
    Change-Id: I4b36c90cd2df844645fd275a41b247352d635727
    Reviewed-on: https://go-review.googlesource.com/c/go/+/533258
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>
    Auto-Submit: Cherry Mui <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

src/runtime/pprof
last known 07496729c58dd58316b01c8bb81aa21a925ae006
current ca7d300509626e2071f3f5babc2e9c121d806fec

commit ca7d300509626e2071f3f5babc2e9c121d806fec
Author: Rhys Hiltner <[email protected]>
Date:   Wed May 29 16:41:10 2024 +0000

    Revert "runtime: remove GODEBUG=runtimecontentionstacks"
    
    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 <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>

commit 9a8995b8b6a08d5fe01122771f962b36336f8aec
Author: Russ Cox <[email protected]>
Date:   Wed May 22 17:09:02 2024 -0400

    all: document legacy //go:linkname for modules with ≥100 dependents
    
    For #67401.
    
    Change-Id: I015408a3f437c1733d97160ef2fb5da6d4efcc5c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/587598
    Reviewed-by: Cherry Mui <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Auto-Submit: Russ Cox <[email protected]>

commit bf91eb3a8bb057a620f3823e4d6b74a529c0a44d
Author: Alan Donovan <[email protected]>
Date:   Thu May 23 10:47:36 2024 -0400

    std: fix calls to Printf(s) with non-constant s
    
    In all cases the intent was not to interpret s as a format string.
    In one case (go/types), this was a latent bug in production.
    (These were uncovered by a new check in vet's printf analyzer.)
    
    Updates #60529
    
    Change-Id: I3e17af7e589be9aec1580783a1b1011c52ec494b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/587855
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Russ Cox <[email protected]>

commit b0b1d42db32a992150dd26681d3bda222e108303
Author: Ian Lance Taylor <[email protected]>
Date:   Wed May 22 13:38:40 2024 -0700

    all: change from sort functions to slices functions where feasible
    
    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 <[email protected]>
    Reviewed-by: Ian Lance Taylor <[email protected]>
    Auto-Submit: Ian Lance Taylor <[email protected]>
    Commit-Queue: Ian Lance Taylor <[email protected]>
    Reviewed-by: Damien Neil <[email protected]>

commit 41884dcd05546ced3634496d931d0b005fc8c2e6
Author: Rhys Hiltner <[email protected]>
Date:   Wed May 22 09:57:14 2024 -0700

    runtime/pprof: ignore runtime-internal samples in test
    
    Tests of the mutex profile focus on sync.Mutex, which is easy to
    control. But since those tests still use the runtime, and contention on
    internal runtime.mutex values is now also part of the mutex profile, we
    have to filter out those samples before examining the profile. Otherwise
    the test may be confused by stray contention on sched.lock (or other
    runtime-internal locks) as a natural consequence of using goroutines.
    
    Fixes #67563
    
    Change-Id: I066a24674d8b719dbeca4a5c0f76b53bc07498c1
    Reviewed-on: https://go-review.googlesource.com/c/go/+/586957
    Reviewed-by: Cherry Mui <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

commit 87e930f7289136fad1310d4b63dd4127e409bac5
Author: Rhys Hiltner <[email protected]>
Date:   Tue May 14 14:44:37 2024 -0700

    runtime: remove GODEBUG=runtimecontentionstacks
    
    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 <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Auto-Submit: Rhys Hiltner <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

commit 1b9dc3e178be578cf1d8c06fe371283a58bdd93f
Author: Felix Geisendörfer <[email protected]>
Date:   Fri May 17 15:07:07 2024 +0200

    runtime: increase profiling stack depth to 128
    
    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 <[email protected]>
    Reviewed-by: Austin Clements <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>

commit 47187a4f4f226c4b9e0e920c5ad1ec9ce83bdc35
Author: Felix Geisendörfer <[email protected]>
Date:   Sun May 19 15:21:53 2024 +0200

    runtime: fix profile stack trace depth regression
    
    Previously it was possible for mutex and block profile stack traces to
    contain up to 32 frames in Stack0 or the resulting pprof profiles.
    CL 533258 changed this behavior by using some of the space to
    record skipped frames that are discarded when performing delayed inline
    expansion. This has lowered the effective maximum stack size from 32 to
    27 (the max skip value is 5), which can be seen as a small regression.
    
    Add TestProfilerStackDepth to demonstrate the issue and protect all
    profile types from similar regressions in the future. Fix the issue by
    increasing the internal maxStack limit to take the maxSkip value into
    account. Assert that the maxSkip value is never exceeded when recording
    mutex and block profile stack traces.
    
    Three alternative solutions to the problem were considered and
    discarded:
    
    1) Revert CL 533258 and give up on frame pointer unwinding. This seems
       unappealing as we would lose the performance benefits of frame
       pointer unwinding.
    2) Discard skipped frames when recording the initial stack trace. This
       would require eager inline expansion for up to maxSkip frames and
       partially negate the performance benefits of frame pointer
       unwinding.
    3) Accept and document the new behavior. This would simplify the
       implementation, but seems more confusing from a user perspective. It
       also complicates the creation of test cases that make assertions
       about the maximum profiling stack depth.
    
    The execution tracer still has the same issue due to CL 463835. This
    should be addressed in a follow-up CL.
    
    Co-authored-by: Nick Ripley <[email protected]>
    Change-Id: Ibf4dbf08a5166c9cb32470068c69f58bc5f98d2c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/586657
    Reviewed-by: Austin Clements <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>