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 8730fcf88531152c42de9ff1e80d9b3c762d9944
current 52eaed66335e90ceb6ad65873889ccca46851ee9

commit 52eaed66335e90ceb6ad65873889ccca46851ee9
Author: Lénaïc Huard <[email protected]>
Date:   Sat Feb 1 14:19:04 2025 +0100

    runtime: decorate anonymous memory mappings
    
    Leverage the prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, ...) API to name
    the anonymous memory areas.
    
    This API has been introduced in Linux 5.17 to decorate the anonymous
    memory areas shown in /proc/<pid>/maps.
    
    This is already used by glibc. See:
    * https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=27dfd1eb907f4615b70c70237c42c552bb4f26a8;hb=HEAD#l2434
    * https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/setvmaname.c;h=ea93a5ffbebc9e5a7e32a297138f465724b4725f;hb=HEAD#l63
    
    This can be useful when investigating the memory consumption of a
    multi-language program.
    On a 100% Go program, pprof profiler can be used to profile the memory
    consumption of the program. But pprof is only aware of what happens
    within the Go world.
    
    On a multi-language program, there could be a doubt about whether the
    suspicious extra-memory consumption comes from the Go part or the native
    part.
    
    With this change, the following Go program:
    
            package main
    
            import (
                    "fmt"
                    "log"
                    "os"
            )
    
            /*
            #include <stdlib.h>
    
            void f(void)
            {
              (void)malloc(1024*1024*1024);
            }
            */
            import "C"
    
            func main() {
                    C.f()
    
                    data, err := os.ReadFile("/proc/self/maps")
                    if err != nil {
                            log.Fatal(err)
                    }
                    fmt.Println(string(data))
            }
    
    produces this output:
    
            $ GLIBC_TUNABLES=glibc.mem.decorate_maps=1 ~/doc/devel/open-source/go/bin/go run .
            00400000-00402000 r--p 00000000 00:21 28451768                           /home/lenaic/.cache/go-build/9f/9f25a17baed5a80d03eb080a2ce2a5ff49c17f9a56e28330f0474a2bb74a30a0-d/test_vma_name
            00402000-004a4000 r-xp 00002000 00:21 28451768                           /home/lenaic/.cache/go-build/9f/9f25a17baed5a80d03eb080a2ce2a5ff49c17f9a56e28330f0474a2bb74a30a0-d/test_vma_name
            004a4000-00574000 r--p 000a4000 00:21 28451768                           /home/lenaic/.cache/go-build/9f/9f25a17baed5a80d03eb080a2ce2a5ff49c17f9a56e28330f0474a2bb74a30a0-d/test_vma_name
            00574000-00575000 r--p 00173000 00:21 28451768                           /home/lenaic/.cache/go-build/9f/9f25a17baed5a80d03eb080a2ce2a5ff49c17f9a56e28330f0474a2bb74a30a0-d/test_vma_name
            00575000-00580000 rw-p 00174000 00:21 28451768                           /home/lenaic/.cache/go-build/9f/9f25a17baed5a80d03eb080a2ce2a5ff49c17f9a56e28330f0474a2bb74a30a0-d/test_vma_name
            00580000-005a4000 rw-p 00000000 00:00 0
            2e075000-2e096000 rw-p 00000000 00:00 0                                  [heap]
            c000000000-c000400000 rw-p 00000000 00:00 0                              [anon: Go: heap]
            c000400000-c004000000 ---p 00000000 00:00 0                              [anon: Go: heap reservation]
            777f40000000-777f40021000 rw-p 00000000 00:00 0                          [anon: glibc: malloc arena]
            777f40021000-777f44000000 ---p 00000000 00:00 0
            777f44000000-777f44021000 rw-p 00000000 00:00 0                          [anon: glibc: malloc arena]
            777f44021000-777f48000000 ---p 00000000 00:00 0
            777f48000000-777f48021000 rw-p 00000000 00:00 0                          [anon: glibc: malloc arena]
            777f48021000-777f4c000000 ---p 00000000 00:00 0
            777f4c000000-777f4c021000 rw-p 00000000 00:00 0                          [anon: glibc: malloc arena]
            777f4c021000-777f50000000 ---p 00000000 00:00 0
            777f50000000-777f50021000 rw-p 00000000 00:00 0                          [anon: glibc: malloc arena]
            777f50021000-777f54000000 ---p 00000000 00:00 0
            777f55afb000-777f55afc000 ---p 00000000 00:00 0
            777f55afc000-777f562fc000 rw-p 00000000 00:00 0                          [anon: glibc: pthread stack: 216378]
            777f562fc000-777f562fd000 ---p 00000000 00:00 0
            777f562fd000-777f56afd000 rw-p 00000000 00:00 0                          [anon: glibc: pthread stack: 216377]
            777f56afd000-777f56afe000 ---p 00000000 00:00 0
            777f56afe000-777f572fe000 rw-p 00000000 00:00 0                          [anon: glibc: pthread stack: 216376]
            777f572fe000-777f572ff000 ---p 00000000 00:00 0
            777f572ff000-777f57aff000 rw-p 00000000 00:00 0                          [anon: glibc: pthread stack: 216375]
            777f57aff000-777f57b00000 ---p 00000000 00:00 0
            777f57b00000-777f58300000 rw-p 00000000 00:00 0                          [anon: glibc: pthread stack: 216374]
            777f58300000-777f58400000 rw-p 00000000 00:00 0                          [anon: Go: page alloc index]
            777f58400000-777f5a400000 rw-p 00000000 00:00 0                          [anon: Go: heap index]
            777f5a400000-777f6a580000 ---p 00000000 00:00 0                          [anon: Go: scavenge index]
            777f6a580000-777f6a581000 rw-p 00000000 00:00 0                          [anon: Go: scavenge index]
            777f6a581000-777f7a400000 ---p 00000000 00:00 0                          [anon: Go: scavenge index]
            777f7a400000-777f8a580000 ---p 00000000 00:00 0                          [anon: Go: page summary]
            777f8a580000-777f8a581000 rw-p 00000000 00:00 0                          [anon: Go: page alloc]
            777f8a581000-777f9c430000 ---p 00000000 00:00 0                          [anon: Go: page summary]
            777f9c430000-777f9c431000 rw-p 00000000 00:00 0                          [anon: Go: page alloc]
            777f9c431000-777f9e806000 ---p 00000000 00:00 0                          [anon: Go: page summary]
            777f9e806000-777f9e807000 rw-p 00000000 00:00 0                          [anon: Go: page alloc]
            777f9e807000-777f9ec00000 ---p 00000000 00:00 0                          [anon: Go: page summary]
            777f9ec36000-777f9ecb6000 rw-p 00000000 00:00 0                          [anon: Go: immortal metadata]
            777f9ecb6000-777f9ecc6000 rw-p 00000000 00:00 0                          [anon: Go: gc bits]
            777f9ecc6000-777f9ecd6000 rw-p 00000000 00:00 0                          [anon: Go: allspans array]
            777f9ecd6000-777f9ece7000 rw-p 00000000 00:00 0                          [anon: Go: immortal metadata]
            777f9ece7000-777f9ed67000 ---p 00000000 00:00 0                          [anon: Go: page summary]
            777f9ed67000-777f9ed68000 rw-p 00000000 00:00 0                          [anon: Go: page alloc]
            777f9ed68000-777f9ede7000 ---p 00000000 00:00 0                          [anon: Go: page summary]
            777f9ede7000-777f9ee07000 rw-p 00000000 00:00 0                          [anon: Go: page alloc]
            777f9ee07000-777f9ee0a000 rw-p 00000000 00:00 0                          [anon: glibc: loader malloc]
            777f9ee0a000-777f9ee2e000 r--p 00000000 00:21 48158213                   /usr/lib/libc.so.6
            777f9ee2e000-777f9ef9f000 r-xp 00024000 00:21 48158213                   /usr/lib/libc.so.6
            777f9ef9f000-777f9efee000 r--p 00195000 00:21 48158213                   /usr/lib/libc.so.6
            777f9efee000-777f9eff2000 r--p 001e3000 00:21 48158213                   /usr/lib/libc.so.6
            777f9eff2000-777f9eff4000 rw-p 001e7000 00:21 48158213                   /usr/lib/libc.so.6
            777f9eff4000-777f9effc000 rw-p 00000000 00:00 0
            777f9effc000-777f9effe000 rw-p 00000000 00:00 0                          [anon: glibc: loader malloc]
            777f9f00a000-777f9f04a000 rw-p 00000000 00:00 0                          [anon: Go: immortal metadata]
            777f9f04a000-777f9f04c000 r--p 00000000 00:00 0                          [vvar]
            777f9f04c000-777f9f04e000 r--p 00000000 00:00 0                          [vvar_vclock]
            777f9f04e000-777f9f050000 r-xp 00000000 00:00 0                          [vdso]
            777f9f050000-777f9f051000 r--p 00000000 00:21 48158204                   /usr/lib/ld-linux-x86-64.so.2
            777f9f051000-777f9f07a000 r-xp 00001000 00:21 48158204                   /usr/lib/ld-linux-x86-64.so.2
            777f9f07a000-777f9f085000 r--p 0002a000 00:21 48158204                   /usr/lib/ld-linux-x86-64.so.2
            777f9f085000-777f9f087000 r--p 00034000 00:21 48158204                   /usr/lib/ld-linux-x86-64.so.2
            777f9f087000-777f9f088000 rw-p 00036000 00:21 48158204                   /usr/lib/ld-linux-x86-64.so.2
            777f9f088000-777f9f089000 rw-p 00000000 00:00 0
            7ffc7bfa7000-7ffc7bfc8000 rw-p 00000000 00:00 0                          [stack]
            ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
    
    The anonymous memory areas are now labelled so that we can see which
    ones have been allocated by the Go runtime versus which ones have been
    allocated by the glibc.
    
    Fixes #71546
    
    Change-Id: I304e8b4dd7f2477a6da794fd44e9a7a5354e4bf4
    Reviewed-on: https://go-review.googlesource.com/c/go/+/646095
    Auto-Submit: Alan Donovan <[email protected]>
    Commit-Queue: Alan Donovan <[email protected]>
    Reviewed-by: Felix Geisendörfer <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Michael Knyszek <[email protected]>
    Reviewed-by: Dmitri Shuralyov <[email protected]>

commit 6c660052856feae2bf1f3fe44665b5da0002500d
Author: Michael Anthony Knyszek <[email protected]>
Date:   Fri Jun 21 17:01:23 2024 +0000

    internal/sync: move sync.Mutex implementation into new package
    
    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 <[email protected]>
    Reviewed-by: David Chase <[email protected]>
    Auto-Submit: Michael Knyszek <[email protected]>

src/runtime/pprof
last known 2a98a1849f059ffa94ab23a1ab7d8fa0fd0b48dd
current 38a2a3c7ce156e01f8980cb97912b7067709aaa3

commit 38a2a3c7ce156e01f8980cb97912b7067709aaa3
Author: apocelipes <[email protected]>
Date:   Tue Apr 8 10:00:13 2025 +0000

    runtime: use internal/byteorder
    
    To simplify the code.
    
    Change-Id: Ib1af5009cc25bb29fd26fdb7b29ff4579f0150aa
    GitHub-Last-Rev: f698a8a771ac8c6ecb745ea4c27a7c677c1789d1
    GitHub-Pull-Request: golang/go#73255
    Reviewed-on: https://go-review.googlesource.com/c/go/+/663735
    Reviewed-by: Carlos Amedee <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>

commit 6fd9ee3da9dc5570f66735e835cac2d66a0f6244
Author: cuishuang <[email protected]>
Date:   Mon Mar 31 18:46:54 2025 +0800

    all: use slices.Equal to simplify code
    
    Change-Id: Ib3be7cee6ca6dce899805aac176ca789eb2fd0f1
    Reviewed-on: https://go-review.googlesource.com/c/go/+/661738
    Reviewed-by: Carlos Amedee <[email protected]>
    Auto-Submit: Sean Liao <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>

commit 7a427143b6ff296125359084a8959bf0c9d23e78
Author: Keith Randall <[email protected]>
Date:   Fri Feb 28 17:01:36 2025 -0800

    cmd/compile: stack allocate variable-sized makeslice
    
    Instead of always allocating variable-sized "make" calls on the heap,
    allocate a small, constant-sized array on the stack and use that array
    as the backing store if it is big enough.
    
    Requires the result of the "make" doesn't escape.
    
      if cap <= K {
          var arr [K]E
          slice = arr[:len:cap]
      } else {
          slice = makeslice(E, len, cap)
      }
    
    Pretty conservatively for now, K = 32/sizeof(E). The slice header is
    already 24 bytes, so wasting 32 bytes of stack if the requested size
    is too big isn't that bad. Larger would waste more stack space but
    maybe avoid more allocations.
    
    This CL also requires the element type be pointer-free.  Maybe we
    could relax that at some point, but it is hard. If the element type
    has pointers we can get heap->stack pointers (in the case where the
    requested size is too big and the slice is heap allocated).
    
    Note that this only handles the case of makeslice called directly from
    compiler-generated code. It does not handle slices built in the
    runtime on behalf of the program (e.g. in growslice). Some of those
    are currently handled by passing in a tmpBuf (e.g. concatstrings),
    but we could probably do more.
    
    Change-Id: I8378efad527cd00d25948a80b82a68d88fbd93a1
    Reviewed-on: https://go-review.googlesource.com/c/go/+/653856
    Reviewed-by: Robert Griesemer <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>

commit 4f11f8ff7db476c534b9b1ad8910dcdd8bbcf022
Author: Michael Pratt <[email protected]>
Date:   Mon Mar 24 04:24:35 2025 -0400

    runtime: rename runfinq to runFinalizersAndCleanups
    
    Users see this frame in tracebacks and it serves as a hint that what is
    running here is a finalizer or cleanup. But runfinq is a rather dense
    name. We can give it a more obvious name to help users realize what it
    is.
    
    For #73011.
    
    Change-Id: I6a6a636ce9a493fd00d4b4c60c23f2b1c96d3568
    Reviewed-on: https://go-review.googlesource.com/c/go/+/660296
    Auto-Submit: Michael Pratt <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Michael Knyszek <[email protected]>

commit 7dd7d70c034a24ac98e52bd4e6dac3ce35c60271
Author: Michael Pratt <[email protected]>
Date:   Mon Mar 17 12:11:42 2025 +0000

    runtime: skip TestCgoCallbackPprof on platforms with broken profiling
    
    CL 658035 added TestCgoCallbackPprof, which is consistently failing on
    solaris. runtime/pprof maintains a list of platforms where CPU profiling
    does not work properly. Since this test requires CPU profiling, skip the
    this test on those platforms.
    
    For #72870.
    Fixes #72876.
    
    Change-Id: I6a6a636cbf6b16abcbba8771178fe1d001be9d9b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/658415
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Auto-Submit: Michael Pratt <[email protected]>
    Reviewed-by: Michael Knyszek <[email protected]>

commit 31658ace9d277b7322413e9c3a21528bdc6db884
Author: Jes Cok <[email protected]>
Date:   Fri Mar 7 01:04:13 2025 +0000

    runtime/internal: clean up completely
    
    We've been slowly moving packages from runtime/internal to
    internal/runtime. For now, runtime/internal only has test packages.
    
    It's a good chance to clean up the references to runtime/internal
    in the toolchain.
    
    For #65355.
    
    Change-Id: Ie6f9091a44511d0db9946ea6de7a78d3afe9f063
    GitHub-Last-Rev: fad32e2e81d11508e734c3c3d3b0c1da583f89f5
    GitHub-Pull-Request: golang/go#72137
    Reviewed-on: https://go-review.googlesource.com/c/go/+/655515
    Reviewed-by: Michael Pratt <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: David Chase <[email protected]>

commit 1cf6b502630034980ba7de8156e4d7c1da7a7845
Author: David Chase <[email protected]>
Date:   Wed Mar 5 14:27:15 2025 -0500

    cmd/compile: remove no-longer-necessary recursive inlining checks
    
    this does result in a little bit more inlining,
    cmd/compile text is 0.5% larger,
    bent-benchmark text geomeans grow by only 0.02%.
    some of our tests make assumptions about inlining.
    
    Change-Id: I999d1798aca5dc64a1928bd434258a61e702951a
    Reviewed-on: https://go-review.googlesource.com/c/go/+/655157
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Keith Randall <[email protected]>
    Reviewed-by: Cuong Manh Le <[email protected]>

commit d0c9142ce3b6fac83dadcc76ecfb85311431e743
Author: Michael Pratt <[email protected]>
Date:   Thu Jan 9 12:22:53 2025 -0500

    runtime/pprof: hide map runtime frames from heap profiles
    
    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 <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Michael Knyszek <[email protected]>

commit 669d87a935536eb14cb2db311a83345359189924
Author: Cosmos Nicolaou <[email protected]>
Date:   Thu Dec 19 15:55:05 2024 -0800

    runtime/pprof: continued attempt to deflake the VMInfo test.
    
    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 <[email protected]>
    Auto-Submit: Michael Pratt <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>

commit a925402b62c06d1cfe2b345cba0b11fa06b8401d
Author: cuishuang <[email protected]>
Date:   Wed Nov 20 21:56:27 2024 +0800

    all: fix some function names and typos in comment
    
    Change-Id: I07e7c8eaa5bd4bac0d576b2f2f4cd3f81b0b77a4
    Reviewed-on: https://go-review.googlesource.com/c/go/+/630055
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Commit-Queue: Ian Lance Taylor <[email protected]>
    Reviewed-by: Ian Lance Taylor <[email protected]>
    Reviewed-by: Russ Cox <[email protected]>
    Auto-Submit: Ian Lance Taylor <[email protected]>

commit ca63101df47a4467bc80faa654fc19d68e583952
Author: Felix Geisendörfer <[email protected]>
Date:   Tue Mar 26 20:23:42 2024 +0100

    runtime/pprof: reduce label overhead
    
    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 <[email protected]>
    Auto-Submit: Felix Geisendörfer <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

commit 8ac0a7c512e7c1bf6fb94feb09b2f878d8eb14a1
Author: Cosmos Nicolaou <[email protected]>
Date:   Fri Feb 2 17:12:27 2024 -0800

    runtime/pprof: continued attempt to deflake the VMInfo test.
    
    This PR will use test.Skip to bypass a test run for which the vmmap
    subprocess appears to hang before the test times out.
    In addition it catches a different error message from vmmap that can
    occur due to transient resource shortages and triggers a retry for
    this additional case.
    
    Fixes #62352
    
    Change-Id: I3ae749e5cd78965c45b1b7c689b896493aa37ba0
    Reviewed-on: https://go-review.googlesource.com/c/go/+/560935
    Reviewed-by: Michael Pratt <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>

commit d7ea9ff50b6c0386c7784b27f66083396fa404af
Author: Sean Liao <[email protected]>
Date:   Fri Jul 12 21:13:20 2024 +0100

    runtime/pprof: note different between go test -memprofile and WriteHeapProfile
    
    Fixes #65328
    
    Change-Id: I11242be93a95e117a6758ac037e143c3b38aa71c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/597980
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Carlos Amedee <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>
    Auto-Submit: Michael Pratt <[email protected]>

commit 411ba0ae8608a0829a185d83f122d83c8a51c754
Author: Felix Geisendörfer <[email protected]>
Date:   Tue Mar 26 20:23:30 2024 +0100

    runtime/pprof: add label benchmark
    
    Add several benchmarks for pprof labels to analyze the impact of
    follow-up CLs.
    
    Change-Id: Ifae39cfe83ec93858fce9e3af6c1be024ba76736
    Reviewed-on: https://go-review.googlesource.com/c/go/+/574515
    Auto-Submit: Ian Lance Taylor <[email protected]>
    Reviewed-by: David Chase <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>

commit e8bb9129d185bf98ba173ec018bf2b6c9d62aa6c
Author: Nick Ripley <[email protected]>
Date:   Fri Nov 1 13:43:34 2024 -0400

    runtime/pprof: relax TestProfilerStackDepth
    
    The TestProfilerStackDepth/heap test can spuriously fail if the profiler
    happens to capture a stack with an allocation several frames deep into
    runtime code. The pprof API hides runtime frames at the leaf-end of
    stacks, but those frames still count against the profiler's stack depth
    limit. The test checks only the first stack it finds with the desired
    prefix and fails if it's not deep enough or doesn't have the right root
    frame. So it can fail in that scenario, even though the implementation
    isn't really broken.
    
    Relax the test to check that there is at least one stack with desired
    prefix, depth, and root frame.
    
    Fixes #70112
    
    Change-Id: I337fb3cccd1ddde76530b03aa1ec0f9608aa4112
    Reviewed-on: https://go-review.googlesource.com/c/go/+/623998
    Reviewed-by: Felix Geisendörfer <[email protected]>
    Reviewed-by: Michael Pratt <[email protected]>
    Reviewed-by: Cherry Mui <[email protected]>
    LUCI-TryBot-Result: Go LUCI <[email protected]>

commit 579eb79f62d92db872d730f5fe954ca2b7dce8ae
Author: Michael Anthony Knyszek <[email protected]>
Date:   Mon Oct 28 17:23:40 2024 +0000

    all: skip and fix various tests with -asan and -msan
    
    First, skip all the allocation count tests.
    
    In some cases this aligns with existing skips for -race, but in others
    we've got new issues. These are debug modes, so some performance loss is
    expected, and this is clearly no worse than today where the tests fail.
    
    Next, skip internal linking and static linking tests for msan and asan.
    
    With asan we get an explicit failure that neither are supported by the C
    and/or Go compilers. With msan, we only get the Go compiler telling us
    internal linking is unavailable. With static linking, we segfault
    instead. Filed #70080 to track that.
    
    Next, skip some malloc tests with asan that don't quite work because of
    the redzone.
    
    This is because of some sizeclass assumptions that get broken with the
    redzone and the fact that the tiny allocator is effectively disabled
    (again, due to the redzone).
    
    Next, skip some runtime/pprof tests with asan, because of extra
    allocations.
    
    Next, skip some malloc tests with asan that also fail because of extra
    allocations.
    
    Next, fix up memstats accounting for arenas when asan is enabled. There
    is a bug where more is added to the stats than subtracted. This also
    simplifies the accounting a little.
    
    Next, skip race tests with msan or asan enabled; they're mutually
    incompatible.
    
    Fixes #70054.
    Fixes #64256.
    Fixes #64257.
    For #70079.
    For #70080.
    
    Change-Id: I99c02a0b9d621e44f1f918b307aa4a4944c3ec60
    Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15
    Reviewed-on: https://go-review.googlesource.com/c/go/+/622855
    Reviewed-by: Cherry Mui <[email protected]>
    TryBot-Bypass: Michael Knyszek <[email protected]>