delta/go-git.git/src/runtime/stack_test.go, branch dev.go2go

runtime: use inlined function name for traceback elision

2020-11-24T21:47:44+00:00

Currently, gentraceback decides which frames to print or elide when
unwinding inlined frames using only the name of the outermost
function. If the outermost function should be elided, then inlined
functions will also be elided, even if they shouldn't be.

This happens in practice in at least one situation. As of CL 258938,
exported Go functions (and functions they call) can now be inlined
into the generated _cgoexp_HASH_FN function. The runtime elides
_cgoexp_HASH_FN from tracebacks because it doesn't contain a ".".
Because of this bug, it also elides anything that was inlined into it.

This CL fixes this by synthesizing a funcInfo for the inlined
functions to pass to showframe.

Fixes #42754.

Change-Id: Ie6c663a4a1ac7f0d4beb1aa60bc26fc8cddd0f9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/272131
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Zhang

runtime: remove unneeded noinline directives

2019-09-17T17:17:11+00:00

Now that mid-stack inlining reports backtraces correctly, we no
longer need to protect against inlining in a few critical areas.

Update #19348
Update #28640
Update #34276

Change-Id: Ie68487e6482c3a9509ecf7ecbbd40fe43cee8381
Reviewed-on: https://go-review.googlesource.com/c/go/+/195818
Reviewed-by: David Chase

Revert "Revert "cmd/compile,runtime: allocate defer records on the stack""

2019-06-10T16:19:39+00:00

This reverts CL 180761

Reason for revert: Reinstate the stack-allocated defer CL.

There was nothing wrong with the CL proper, but stack allocation of defers exposed two other issues.

Issue #32477: Fix has been submitted as CL 181258.
Issue #32498: Possible fix is CL 181377 (not submitted yet).

Change-Id: I32b3365d5026600069291b068bbba6cb15295eb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/181378
Reviewed-by: Brad Fitzpatrick

Revert "cmd/compile,runtime: allocate defer records on the stack"

2019-06-05T19:50:09+00:00

This reverts commit fff4f599fe1c21e411a99de5c9b3777d06ce0ce6.

Reason for revert: Seems to still have issues around GC.

Fixes #32452

Change-Id: Ibe7af629f9ad6a3d5312acd7b066123f484da7f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/180761
Run-TryBot: Keith Randall 
TryBot-Result: Gobot Gobot 
Reviewed-by: Josh Bleecher Snyder

cmd/compile,runtime: allocate defer records on the stack

2019-06-04T17:35:20+00:00

When a defer is executed at most once in a function body,
we can allocate the defer record for it on the stack instead
of on the heap.

This should make defers like this (which are very common) faster.

This optimization applies to 363 out of the 370 static defer sites
in the cmd/go binary.

name     old time/op  new time/op  delta
Defer-4  52.2ns ± 5%  36.2ns ± 3%  -30.70%  (p=0.000 n=10+10)

Fixes #6980
Update #14939

Change-Id: I697109dd7aeef9e97a9eeba2ef65ff53d3ee1004
Reviewed-on: https://go-review.googlesource.com/c/go/+/171758
Run-TryBot: Keith Randall 
TryBot-Result: Gobot Gobot 
Reviewed-by: Austin Clements

runtime: disable some tests in -quick mode

2019-05-16T03:25:03+00:00

Speeds up the "go test runtime -cpu=1,2,4 -short -quick" phase of all.bash.

For #26473.

Change-Id: I090f5a5aa754462b3253a2156dc31fa67ce7af2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/177399
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick 
Reviewed-by: Austin Clements

runtime: scan defer closure in stack scan

2019-03-01T16:21:29+00:00

With stack objects, when we scan the stack, it scans defers with
tracebackdefers, but it seems to me that tracebackdefers doesn't
include the func value itself, which could be a stack allocated
closure. Scan it explicitly.

Alternatively, we can change tracebackdefers to include the func
value, which in turn needs to change the type of stkframe.

Fixes #30453.

Change-Id: I55a6e43264d6952ab2fa5c638bebb89fdc410e2b
Reviewed-on: https://go-review.googlesource.com/c/164118
Reviewed-by: Keith Randall

cmd/compile: encourage inlining of functions with single-call bodies

2018-11-08T17:29:23+00:00

This is a simple tweak to allow a bit more mid-stack inlining.
In cases like this:

func f() {
    g()
}

We'd really like to inline f into its callers. It can't hurt.

We implement this optimization by making calls a bit cheaper, enough
to afford a single call in the function body, but not 2.
The remaining budget allows for some argument modification, or perhaps
a wrapping conditional:

func f(x int) {
    g(x, 0)
}
func f(x int) {
    if x > 0 {
        g()
    }
}

Update #19348

Change-Id: Ifb1ea0dd1db216c3fd5c453c31c3355561fe406f
Reviewed-on: https://go-review.googlesource.com/c/147361
Reviewed-by: Austin Clements 
Reviewed-by: David Chase

runtime: scale timeout in TestStackGrowth

2018-07-09T02:18:16+00:00

Updates #19381

Change-Id: I62b8b0cd7170941af77281eb3aada3802623ec27
Reviewed-on: https://go-review.googlesource.com/122587
Reviewed-by: Brad Fitzpatrick

runtime: fix defer matching of leaf functions on LR machines

2018-05-22T19:38:03+00:00

Traceback matches the defer stack with the function call stack using
the SP recorded in defer frames when the defer frame is created.
However, on LR machines this is ambiguous: if function A pushes a
defer and then calls function B, where B is a leaf function with a
zero-sized frame, then both A and B have the same SP and will *both*
match the defer on the defer stack. Since traceback unwinds through B
first, it will incorrectly match up the defer with B's frame instead
of A's frame.

Where this goes particularly wrong is if function B causes a signal
that turns into a panic (e.g., a nil pointer dereference). In order to
handle the fact that we may not have a liveness map at the location
that caused the signal and injected a sigpanic call, traceback has
logic to unwind the panicking frame's continuation PC to the PC where
the most recent defer was pushed (this is safe because the frame is
dead other than any defers it pushed). However, if traceback
mis-matches the defer stack, it winds up reporting the B's
continuation PC is in A. If the runtime then uses this continuation PC
to look up PCDATA in B, it will panic because the PC is out of range
for B. This failure mode can be seen in
sync/atomic/atomic_test.go:TestNilDeref. An example failure is:
https://build.golang.org/log/8e07a762487839252af902355f6b1379dbd463c5

This CL fixes all of this by recognizing that a function that pushes a
defer must also have a non-zero-sized frame and using this fact to
refine the defer matching logic.

Fixes the build for arm64, mips, mipsle, ppc64, ppc64le, and s390x.

Fixes #25499.

Change-Id: Iff7c01d08ad42f3de22b3a73658cc2f674900101
Reviewed-on: https://go-review.googlesource.com/114078
Run-TryBot: Austin Clements 
TryBot-Result: Gobot Gobot 
Reviewed-by: Keith Randall