Change-Id: I02c4664f1ba72623a5470e92bbebabb2f4862428
Reviewed-on: https://go-review.googlesource.com/c/go/+/428264
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: Ibab20627ccd1f79e77e3972e2bc6ca42c2c7de13
Reviewed-on: https://go-review.googlesource.com/c/go/+/428263
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I0a51aa9e7800689c123ce3eaf74742a4641b7681
Reviewed-on: https://go-review.googlesource.com/c/go/+/428261
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Iab6ef8c6c74c09e8358f7d7088a82089725479ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/428260
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: Iee846c4ac0f111ff97aa618dd42f6b2d14aa4342
Reviewed-on: https://go-review.googlesource.com/c/go/+/428259
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Change-Id: Ib07699df8ea41fd8d1bca8ad050859fac24623de
Reviewed-on: https://go-review.googlesource.com/c/go/+/428258
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: I59db11212758b478248f34c031501a167335348c
Reviewed-on: https://go-review.googlesource.com/c/go/+/428257
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Ief82f12a5c48c46165c28140997d5fc83700c758
Reviewed-on: https://go-review.googlesource.com/c/go/+/428256
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: I07e022ffc022bca6aa12165871e723db3ed83141
Reviewed-on: https://go-review.googlesource.com/c/go/+/428255
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Change-Id: Icb53d32f2de13287b1b4f4f67dab90fe5ee7a3df
Reviewed-on: https://go-review.googlesource.com/c/go/+/428254
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
This reverts https://go.dev/cl/427135.
Reason for revert: broke the test it modified on linux-amd64-noopt.
--- FAIL: TestDebugCallUnsafePoint (0.00s)
debug_test.go:265: want "call not at safe point", got %!s(<nil>)
Change-Id: I044c9720aed2d5e48b56bd7ab2781462270dcae9
Reviewed-on: https://go-review.googlesource.com/c/go/+/428395
Reviewed-by: xie cui <523516579@qq.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: hopehook <hopehook@golangcn.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Change-Id: Ic7f827b8ee758c991ed76be65026b0330207deea
Reviewed-on: https://go-review.googlesource.com/c/go/+/428262
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This reverts https://go.dev/cl/425881.
Reason for revert: broke make.bash on linux/amd64 with Linux 5.19.6.
[...]
Building Go toolchain2 using go_bootstrap and Go toolchain1.
go install internal/unsafeheader: copying /tmp/go-build4206185186/b007/_pkg_.a to /home/mvdan/tip/pkg/linux_amd64/internal/unsafeheader.a: write /home/mvdan/tip/pkg/linux_amd64/internal/unsafeheader.a: copy_file_range: invalid cross-device link
go install internal/goarch: copying /tmp/go-build4206185186/b006/_pkg_.a to /home/mvdan/tip/pkg/linux_amd64/internal/goarch.a: write /home/mvdan/tip/pkg/linux_amd64/internal/goarch.a: copy_file_range: invalid cross-device link
[...]
Change-Id: I793856935d4315a870c2d31da46be00cc342b5f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/428396
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: hopehook <hopehook@golangcn.org>
Reviewed-by: Andy Pan <panjf2000@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
A few minor improvements for KernelVersion for the sake of readability.
Change-Id: I06d2df60ecee8ee0ae603952470fb73e7dcd5d74
Reviewed-on: https://go-review.googlesource.com/c/go/+/427676
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Since values[2] elements are initialized with 0, the switch statement
doesn't do anything. Remove it.
Change-Id: I41176692cdf0c01fe8e85315f0c0dc8b0f3d41fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/427675
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Use an atomic.Uint32 to represent the state of finalizer goroutine.
fingStatus will only be changed to fingWake in non fingWait state,
so it is safe to set fingRunningFinalizer status in runfinq.
name old time/op new time/op delta
Finalizer-8 592µs ± 4% 561µs ± 1% -5.22% (p=0.000 n=10+10)
FinalizerRun-8 694ns ± 6% 675ns ± 7% ~ (p=0.059 n=9+8)
Change-Id: I7e4da30cec98ce99f7d8cf4c97f933a8a2d1cae1
Reviewed-on: https://go-review.googlesource.com/c/go/+/400134
Reviewed-by: Joedian Reid <joedian@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Pratt <mpratt@google.com>
The initial CL 229101 didn't limit the kernel version, but relies on error checking to
ensure the kernel version >= 4.5 or >= 5.3 when it's calling copy_file_range(2) to copy data across file systems.
Since we have now put the kernel version checking at the beginning of the function, introduced by CL 268338,
which returns early instead of going forward to the code behind when the kernel verion is older than 5.3,
therefore, those subsequent related error checks are no longer needed.
Change-Id: Ifc4a530723e21f0bde91d6420cde9cb676081922
Reviewed-on: https://go-review.googlesource.com/c/go/+/425881
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: hopehook <hopehook@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Consistently wait for idle connections to become readable before
starting the ReadHeaderTimeout timer. Previously, connections with no
idle timeout skipped directly to reading headers, so the
ReadHeaderTimeout also included time spent idle.
Fixes#54784
Change-Id: Iff1a876f00311d03dfa0fbef5b577506c62f7c41
GitHub-Last-Rev: 09332743ad
GitHub-Pull-Request: golang/go#54785
Reviewed-on: https://go-review.googlesource.com/c/go/+/426895
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
As net package has one of the biggest init time in standard library, I have tried to improve performance by doing two things in net/addrselect.go:
1. Precompute slice with RFC rules. Currently the rules are computed and sorted in init() function. We could save the time and allocations by using prepopulated values in sorted manner. The rules haven't changed since 2015. To be extra safe we could move order validation as test case. It should slightly speed up startup of each binary with "net" package and go dns resolver. It also saves 38 allocations, ~50% of allocations in init phase of `net` module.
2. Replace internal net.IP usage with netip.Addr in `sortByRFC6724` function. It results in ~40% performance improvement on samples from tests.
The only risk is the difference between net.IP and netip.Addr behaviour.
Init benchmark:
Init-8 1.89µs ± 2% 0.12µs ± 3% -93.79% (p=0.000 n=5+5)
name old alloc/op new alloc/op delta
Init-8 1.05kB ± 0% 0.38kB ± 0% ~ (zero variance)
name old allocs/op new allocs/op delta
Init-8 39.0 ± 0% 1.0 ± 0% ~ (zero variance)
Whole sortByRFC6724 function benchmark:
name old time/op new time/op delta
SortByRFC6724/0-8 463ns ± 3% 303ns ± 4% -34.72% (p=0.000 n=5+5)
SortByRFC6724/1-8 481ns ± 8% 306ns ± 1% -36.46% (p=0.000 n=5+5)
SortByRFC6724/2-8 470ns ± 4% 307ns ± 4% -34.77% (p=0.000 n=5+5)
SortByRFC6724/3-8 567ns ± 3% 367ns ± 3% -35.28% (p=0.000 n=5+5)
SortByRFC6724/4-8 918ns ± 3% 560ns ± 2% -38.93% (p=0.000 n=5+5)
Updates #54032
Change-Id: Ic18df1ea73805cb184c6ceb73470ca7f0b922032
Reviewed-on: https://go-review.googlesource.com/c/go/+/419356
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Note that this changes some unsynchronized operations of g.atomicstatus to synchronized operations.
Updates #53821
Change-Id: If249d62420ea09fbec39b570942f96c63669c333
Reviewed-on: https://go-review.googlesource.com/c/go/+/425363
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
So it's consistent when running "go list -f '{{context.ToolTags}}'" and
printing the content of "build.Default.ToolTags".
Updates #45454
Change-Id: I7a3cbf3cdf9a6ce2b8c89e9bcf5fc5e9086d48e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/422615
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
as setup by the kernel on GOARCH=arm64.
Update #50947
Change-Id: I2f44be9b36e9ce8d264eccc0aa3df10825c5f4f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/422977
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Dmitri Goutnik <dgoutnik@gmail.com>
Run-TryBot: Yuval Pavel Zholkover <paulzhol@gmail.com>
Currently, there are 3 functions returning Linux kernel version numbers.
Two of them are identical:
- in net, initially added by commit 0a9dd47dd817904e;
- in internal/poll, initially added by commit 1c7650aa93bd53;
(both were later fixed by commit 66c0264506).
The third one is a more complex, regexp-based implementation in
runtime/pprof, which is only used for a test.
Instead of adding one more, let's consolidate existing ones.
Remove the complex implementation, and move the simple one into
internal/syscall/unix. Use it from all the three places mentioned above.
Change-Id: I4a34d9ca47257743c16def30e4dd634e36056091
Reviewed-on: https://go-review.googlesource.com/c/go/+/424896
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also, consistently use declaration: var buf strings.Builder.
We don't change exported signatures to match go/types (where we
can't change the exported signatures for backward-compatibility).
Change-Id: I75350886aa231889ae2fd5c4008dd4be9ed6e09f
Reviewed-on: https://go-review.googlesource.com/c/go/+/428094
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The kernel knob /proc/sys/kernel/unprivileged_userns_clone is
only available in Debian (and Ubuntu) kernels, so if the tests
are run on e.g. Fedora, skipUnprivilegedUserClone() skips a lot
of tests.
Modify it to treat ENOENT as "it should work".
Change-Id: I959201ede139ede989cc8ab646c9bf51e0539ada
Reviewed-on: https://go-review.googlesource.com/c/go/+/417694
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Previously when a printer had a large buffer we dropped both
the buffer and the printer. There is no need to drop the printer
in this case, as a printer with a nil buffer is valid. So we
just drop the buffer and recycle the printer anyway.
This saves one allocation in case the buffer is over the limit.
Also tighten some of the tests for other unrelated cases.
Change-Id: Iba1b6a71ca4691464b8c68ab0b6ab0d4d5d6168c
Reviewed-on: https://go-review.googlesource.com/c/go/+/427395
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, the itabs section for runtime dictionaries includes its own
redundant *runtime._type pointers for typ and iface, which were
sometimes necessary. This simplified the initial implementation, but
is a little wasteful of space when the same type or interface appeared
across multiple (typ, iface) pairs.
This CL instead reuses the pointers from the rtypes section.
Change-Id: I48448515c319c0403c1a8e7706794d443176f0a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/427754
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Convert subtraction from const to a negated ADDI with negative const
value, where possible. At worst this avoids a register load and uses
the same number of instructions. At best, this allows for further
optimisation to occur, particularly where equality is involved.
For example, this sequence:
li t0,-1
sub t1,t0,a0
snez t1,t1
Becomes:
addi t0,a0,1
snez t0,t0
Removes more than 2000 instructions from the Go binary on linux/riscv64.
Change-Id: I68f3be897bc645d4a8fa3ab3cef165a00a74df19
Reviewed-on: https://go-review.googlesource.com/c/go/+/426263
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
The FNES and FNED instructions are pseudo-instructions, which the
assembler expands to FEQS/NEG or FEQD/NEG - if we're comparing the
result via a branch instruction, we can avoid an instruction by
negating both the branch comparision and the floating point
comparision.
This only removes a handful of instructions from the Go binary,
however, it will provide benefit to floating point intensive code.
Change-Id: I4e3124440b7659acc4d9bc9948b755a4900a422f
Reviewed-on: https://go-review.googlesource.com/c/go/+/426261
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Currently these are only implicitly documented by the code that
generates and consumes them. Add explicit documentation.
Change-Id: I25a1294f04dc11785242643bec83370c66ff7a20
Reviewed-on: https://go-review.googlesource.com/c/go/+/427954
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Use the same spacing convention ("x | y") for union terms everythere,
matching the gofmt precedent.
Fixes#53279.
Change-Id: Ic3ccd7433b5f62402ba41cf05a75f9a1d99a8086
Reviewed-on: https://go-review.googlesource.com/c/go/+/410955
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Use an early return to reduce indentation and clarify flow.
For #54466.
Change-Id: I12ce810bea0f22b8707a175dc5ba66241c0a9a21
Reviewed-on: https://go-review.googlesource.com/c/go/+/425936
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The stkframe struct and its methods are strewn across different source
files. Since they actually have a pretty coherent theme at this point,
migrate it all into a new file, stkframe.go. There are no code changes
in this CL.
For #54466, albeit rather indirectly.
Change-Id: Ibe53fc4b1106d131005e1c9d491be838a8f14211
Reviewed-on: https://go-review.googlesource.com/c/go/+/424516
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
This places getStackMap alongside argBytes and argMapInternal as
another method of stkframe.
For #54466, albeit rather indirectly.
Change-Id: I411dda3605dd7f996983706afcbefddf29a68a85
Reviewed-on: https://go-review.googlesource.com/c/go/+/424515
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, stkframe.arglen and stkframe.argmap are populated by
gentraceback under a particular set of circumstances. But because they
can be constructed from other fields in stkframe, they don't need to
be computed eagerly at all. They're also rather misleading, as they're
only part of computing the actual argument map and most callers should
be using getStackMap, which does the rest of the work.
This CL drops these fields from stkframe. It shifts the functions that
used to compute them, getArgInfoFast and getArgInfo, into
corresponding methods stkframe.argBytes and stkframe.argMapInternal.
argBytes is expected to be used by callers that need to know only the
argument frame size, while argMapInternal is used only by argBytes and
getStackMap.
We also move some of the logic from getStackMap into argMapInternal
because the previous split of responsibilities didn't make much sense.
This lets us return just a bitvector from argMapInternal, rather than
both a bitvector, which carries a size, and an "actually use this
size".
The getArgInfoFast function was inlined before (and inl_test checked
this). We drop that requirement from stkframe.argBytes because the
uses of this have shifted and now it's only called from heap dumping
(which never happens) and conservative stack frame scanning (which
very, very rarely happens).
There will be a few follow-up clean-up CLs.
For #54466. This is a nice clean-up on its own, but it also serves to
remove pointers from the traceback state that would eventually become
troublesome write barriers once we stack-rip gentraceback.
Change-Id: I107f98ed8e7b00185c081de425bbf24af02a4163
Reviewed-on: https://go-review.googlesource.com/c/go/+/424514
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, when traceback jumps from the system stack to a user stack
(e.g., during profiling tracebacks), it leaves gp pointing at the g0.
This is currently harmless since it's only used during profiling, so
the code paths in gentraceback that care about gp aren't used, but
it's really confusing and would certainly break if _TraceJumpStack
were ever used in a context other than profiling.
Fix this by updating gp to point to the user g when we switch stacks.
For #54466.
Change-Id: I1541e004667a52e37671803ce45c91d8c5308830
Reviewed-on: https://go-review.googlesource.com/c/go/+/424257
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
The meaning of some of the fields in stkframe is actually quite
subtle.
Change-Id: Iac765ff6fbf4c3b7c9f2453f5b4a2e5e640f5750
Reviewed-on: https://go-review.googlesource.com/c/go/+/424256
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Austin Clements <austin@google.com>
The f funcInfo argument is always the same as frame.fn, so we don't
need to pass it. I suspect that was there to make the signatures of
getArgInfoFast and getArgInfo more similar, but it's not necessary.
For #54466.
Change-Id: Idc717f4df09e97cad49d52c5b7edf28090908cba
Reviewed-on: https://go-review.googlesource.com/c/go/+/424255
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, gentraceback tracks the closure context of the outermost
frame. This used to be important for "unstarted" calls to reflect
function stubs, where "unstarted" calls are either deferred functions
or the entry-point of a goroutine that hasn't run. Because reflect
function stubs have a dynamic argument map, we have to reach into
their closure context to fetch to map, and how to do this differs
depending on whether the function has started. This was discovered in
issue #25897.
However, as part of the register ABI, "go" and "defer" were made much
simpler, and any "go" or "defer" of a function that takes arguments or
returns results gets wrapped in a closure that provides those
arguments (and/or discards the results). Hence, we'll see that closure
instead of a direct call to a reflect stub, and can get its static
argument map without any trouble.
The one case where we may still see an unstarted reflect stub is if
the function takes no arguments and has no results, in which case the
compiler can optimize away the wrapper closure. But in this case we
know the argument map is empty: the compiler can apply this
optimization precisely because the target function has no argument
frame.
As a result, we no longer need to track the closure context during
traceback, so this CL drops all of that mechanism.
We still have to be careful about the unstarted case because we can't
reach into the function's locals frame to pull out its context
(because it has no locals frame). We double-check that in this case
we're at the function entry.
I would prefer to do this with some in-code PCDATA annotations of
where to find the dynamic argument map, but that's a lot of mechanism
to introduce for just this. It might make sense to consider this along
with #53609.
Finally, we beef up the test for this so it more reliably forces the
runtime down this path. It's fundamentally probabilistic, but this
tweak makes it better. Scheduler testing hooks (#54475) would make it
possible to write a reliable test for this.
For #54466, but it's a nice clean-up all on its own.
Change-Id: I16e4f2364ba2ea4b1fec1e27f971b06756e7b09f
Reviewed-on: https://go-review.googlesource.com/c/go/+/424254
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
