2012-09-23 11:16:14 -06:00
|
|
|
// errorcheck -0 -m -l
|
2011-08-24 11:07:08 -06:00
|
|
|
|
2016-04-10 15:32:26 -06:00
|
|
|
// Copyright 2010 The Go Authors. All rights reserved.
|
2011-08-24 11:07:08 -06:00
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
2012-02-18 20:28:53 -07:00
|
|
|
// Test, using compiler diagnostic flags, that the escape analysis is working.
|
2012-02-23 21:09:53 -07:00
|
|
|
// Compiles but does not run. Inlining is disabled.
|
2012-02-18 20:28:53 -07:00
|
|
|
|
2014-09-24 13:20:03 -06:00
|
|
|
// escape2n.go contains all the same tests but compiles with -N.
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
package foo
|
|
|
|
|
2011-11-01 09:02:43 -06:00
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
"unsafe"
|
|
|
|
)
|
2011-08-24 11:07:08 -06:00
|
|
|
|
|
|
|
var gxx *int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo1(x int) { // ERROR "moved to heap: x$"
|
|
|
|
gxx = &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo2(yy *int) { // ERROR "leaking param: yy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
gxx = yy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo3(x int) *int { // ERROR "moved to heap: x$"
|
|
|
|
return &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
type T *T
|
2011-08-28 10:05:00 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo3b(t T) { // ERROR "leaking param: t$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*t = t
|
|
|
|
}
|
|
|
|
|
|
|
|
// xx isn't going anywhere, so use of yy is ok
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo4(xx, yy *int) { // ERROR "foo4 xx does not escape$" "foo4 yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
xx = yy
|
|
|
|
}
|
|
|
|
|
|
|
|
// xx isn't going anywhere, so taking address of yy is ok
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo5(xx **int, yy *int) { // ERROR "foo5 xx does not escape$" "foo5 yy does not escape$"
|
|
|
|
xx = &yy // ERROR "foo5 &yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo6(xx **int, yy *int) { // ERROR "foo6 xx does not escape$" "leaking param: yy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xx = yy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo7(xx **int, yy *int) { // ERROR "foo7 xx does not escape$" "foo7 yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
**xx = *yy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo8(xx, yy *int) int { // ERROR "foo8 xx does not escape$" "foo8 yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
xx = yy
|
|
|
|
return *xx
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo9(xx, yy *int) *int { // ERROR "leaking param: xx to result ~r2 level=0$" "leaking param: yy to result ~r2 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
xx = yy
|
|
|
|
return xx
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo10(xx, yy *int) { // ERROR "foo10 xx does not escape$" "foo10 yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xx = *yy
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo11() int {
|
|
|
|
x, y := 0, 42
|
2015-02-19 12:00:11 -07:00
|
|
|
xx := &x // ERROR "foo11 &x does not escape$"
|
|
|
|
yy := &y // ERROR "foo11 &y does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xx = *yy
|
|
|
|
return x
|
|
|
|
}
|
|
|
|
|
|
|
|
var xxx **int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo12(yyy **int) { // ERROR "leaking param: yyy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
xxx = yyy
|
|
|
|
}
|
|
|
|
|
2014-05-09 13:40:45 -06:00
|
|
|
// Must treat yyy as leaking because *yyy leaks, and the escape analysis
|
2013-03-15 02:03:45 -06:00
|
|
|
// summaries in exported metadata do not distinguish these two cases.
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo13(yyy **int) { // ERROR "leaking param content: yyy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xxx = *yyy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo14(yyy **int) { // ERROR "foo14 yyy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
**xxx = **yyy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo15(yy *int) { // ERROR "moved to heap: yy$"
|
|
|
|
xxx = &yy // ERROR "&yy escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo16(yy *int) { // ERROR "leaking param: yy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xxx = yy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo17(yy *int) { // ERROR "foo17 yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
**xxx = *yy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo18(y int) { // ERROR "moved to heap: y$"
|
|
|
|
*xxx = &y // ERROR "&y escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo19(y int) {
|
|
|
|
**xxx = y
|
|
|
|
}
|
|
|
|
|
|
|
|
type Bar struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
i int
|
2011-08-24 11:07:08 -06:00
|
|
|
ii *int
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewBar() *Bar {
|
2015-02-19 12:00:11 -07:00
|
|
|
return &Bar{42, nil} // ERROR "&Bar literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func NewBarp(x *int) *Bar { // ERROR "leaking param: x to result ~r1 level=-1$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return &Bar{42, x} // ERROR "&Bar literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func NewBarp2(x *int) *Bar { // ERROR "NewBarp2 x does not escape$"
|
|
|
|
return &Bar{*x, nil} // ERROR "&Bar literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Bar) NoLeak() int { // ERROR "\(\*Bar\).NoLeak b does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return *(b.ii)
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar) Leak() *int { // ERROR "leaking param: b to result ~r0 level=0$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return &b.i // ERROR "&b.i escapes to heap$"
|
2012-01-12 04:08:40 -07:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar) AlsoNoLeak() *int { // ERROR "leaking param: b to result ~r0 level=1$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return b.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b Bar) AlsoLeak() *int { // ERROR "leaking param: b to result ~r0 level=0$"
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b Bar) LeaksToo() *int { // ERROR "leaking param: b to result ~r0 level=0$"
|
2015-02-19 12:00:11 -07:00
|
|
|
v := 0 // ERROR "moved to heap: v$"
|
|
|
|
b.ii = &v // ERROR "&v escapes to heap$"
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar) LeaksABit() *int { // ERROR "leaking param: b to result ~r0 level=1$"
|
2015-02-19 12:00:11 -07:00
|
|
|
v := 0 // ERROR "moved to heap: v$"
|
|
|
|
b.ii = &v // ERROR "&v escapes to heap$"
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.ii
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b Bar) StillNoLeak() int { // ERROR "Bar.StillNoLeak b does not escape$"
|
2012-01-12 04:08:40 -07:00
|
|
|
v := 0
|
2015-02-19 12:00:11 -07:00
|
|
|
b.ii = &v // ERROR "Bar.StillNoLeak &v does not escape$"
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.i
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func goLeak(b *Bar) { // ERROR "leaking param: b$"
|
2011-09-07 11:03:11 -06:00
|
|
|
go b.NoLeak()
|
|
|
|
}
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
type Bar2 struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
i [12]int
|
2011-08-24 11:07:08 -06:00
|
|
|
ii []int
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewBar2() *Bar2 {
|
2015-02-19 12:00:11 -07:00
|
|
|
return &Bar2{[12]int{42}, nil} // ERROR "&Bar2 literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Bar2) NoLeak() int { // ERROR "\(\*Bar2\).NoLeak b does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return b.i[0]
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar2) Leak() []int { // ERROR "leaking param: b to result ~r0 level=0$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return b.i[:] // ERROR "b.i escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar2) AlsoNoLeak() []int { // ERROR "leaking param: b to result ~r0 level=1$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return b.ii[0:1]
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b Bar2) AgainNoLeak() [12]int { // ERROR "Bar2.AgainNoLeak b does not escape$"
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.i
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Bar2) LeakSelf() { // ERROR "leaking param: b$"
|
|
|
|
b.ii = b.i[0:4] // ERROR "b.i escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Bar2) LeakSelf2() { // ERROR "leaking param: b$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var buf []int
|
2015-02-19 12:00:11 -07:00
|
|
|
buf = b.i[0:] // ERROR "b.i escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
b.ii = buf
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo21() func() int {
|
2015-01-19 12:59:58 -07:00
|
|
|
x := 42
|
2015-02-19 12:00:11 -07:00
|
|
|
return func() int { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo21a() func() int {
|
2015-02-19 12:00:11 -07:00
|
|
|
x := 42 // ERROR "moved to heap: x$"
|
|
|
|
return func() int { // ERROR "func literal escapes to heap$"
|
|
|
|
x++ // ERROR "&x escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo22() int {
|
|
|
|
x := 42
|
2015-02-19 12:00:11 -07:00
|
|
|
return func() int { // ERROR "foo22 func literal does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return x
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
2015-01-19 12:59:58 -07:00
|
|
|
func foo23(x int) func() int {
|
2015-02-19 12:00:11 -07:00
|
|
|
return func() int { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-19 12:59:58 -07:00
|
|
|
func foo23a(x int) func() int {
|
2015-02-19 12:00:11 -07:00
|
|
|
f := func() int { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
return f
|
|
|
|
}
|
|
|
|
|
2015-01-19 12:59:58 -07:00
|
|
|
func foo23b(x int) *(func() int) {
|
2015-02-19 12:00:11 -07:00
|
|
|
f := func() int { return x } // ERROR "func literal escapes to heap$" "moved to heap: f$"
|
|
|
|
return &f // ERROR "&f escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo23c(x int) func() int { // ERROR "moved to heap: x$"
|
|
|
|
return func() int { // ERROR "func literal escapes to heap$"
|
|
|
|
x++ // ERROR "&x escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
func foo24(x int) int {
|
2015-02-19 12:00:11 -07:00
|
|
|
return func() int { // ERROR "foo24 func literal does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return x
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
var x *int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func fooleak(xx *int) int { // ERROR "leaking param: xx$"
|
2011-08-24 11:07:08 -06:00
|
|
|
x = xx
|
|
|
|
return *x
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foonoleak(xx *int) int { // ERROR "foonoleak xx does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return *x + *xx
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo31(x int) int { // ERROR "moved to heap: x$"
|
|
|
|
return fooleak(&x) // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo32(x int) int {
|
2015-02-19 12:00:11 -07:00
|
|
|
return foonoleak(&x) // ERROR "foo32 &x does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
type Foo struct {
|
|
|
|
xx *int
|
2011-08-28 10:05:00 -06:00
|
|
|
x int
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
var F Foo
|
|
|
|
var pf *Foo
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) fooleak() { // ERROR "leaking param: f$"
|
2011-08-24 11:07:08 -06:00
|
|
|
pf = f
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) foonoleak() { // ERROR "\(\*Foo\).foonoleak f does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
F.x = f.x
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) Leak() { // ERROR "leaking param: f$"
|
2011-08-24 11:07:08 -06:00
|
|
|
f.fooleak()
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) NoLeak() { // ERROR "\(\*Foo\).NoLeak f does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
f.foonoleak()
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo41(x int) { // ERROR "moved to heap: x$"
|
|
|
|
F.xx = &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) foo42(x int) { // ERROR "\(\*Foo\).foo42 f does not escape$" "moved to heap: x$"
|
|
|
|
f.xx = &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo43(f *Foo, x int) { // ERROR "foo43 f does not escape$" "moved to heap: x$"
|
|
|
|
f.xx = &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo44(yy *int) { // ERROR "leaking param: yy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
F.xx = yy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) foo45() { // ERROR "\(\*Foo\).foo45 f does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
F.x = f.x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2013-03-15 02:03:45 -06:00
|
|
|
// See foo13 above for explanation of why f leaks.
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (f *Foo) foo46() { // ERROR "leaking param content: f$"
|
2011-08-28 10:05:00 -06:00
|
|
|
F.xx = f.xx
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) foo47() { // ERROR "leaking param: f$"
|
|
|
|
f.xx = &f.x // ERROR "&f.x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
var ptrSlice []*int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo50(i *int) { // ERROR "leaking param: i$"
|
2011-08-24 11:07:08 -06:00
|
|
|
ptrSlice[0] = i
|
|
|
|
}
|
|
|
|
|
|
|
|
var ptrMap map[*int]*int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo51(i *int) { // ERROR "leaking param: i$"
|
2011-08-24 11:07:08 -06:00
|
|
|
ptrMap[i] = i
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func indaddr1(x int) *int { // ERROR "moved to heap: x$"
|
|
|
|
return &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func indaddr2(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return *&x // ERROR "indaddr2 &x does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func indaddr3(x *int32) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return *(**int)(unsafe.Pointer(&x)) // ERROR "indaddr3 &x does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// From package math:
|
|
|
|
|
|
|
|
func Float32bits(f float32) uint32 {
|
2015-02-19 12:00:11 -07:00
|
|
|
return *(*uint32)(unsafe.Pointer(&f)) // ERROR "Float32bits &f does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func Float32frombits(b uint32) float32 {
|
2015-02-19 12:00:11 -07:00
|
|
|
return *(*float32)(unsafe.Pointer(&b)) // ERROR "Float32frombits &b does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func Float64bits(f float64) uint64 {
|
2015-02-19 12:00:11 -07:00
|
|
|
return *(*uint64)(unsafe.Pointer(&f)) // ERROR "Float64bits &f does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func Float64frombits(b uint64) float64 {
|
2015-02-19 12:00:11 -07:00
|
|
|
return *(*float64)(unsafe.Pointer(&b)) // ERROR "Float64frombits &b does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// contrast with
|
2015-02-19 12:00:11 -07:00
|
|
|
func float64bitsptr(f float64) *uint64 { // ERROR "moved to heap: f$"
|
|
|
|
return (*uint64)(unsafe.Pointer(&f)) // ERROR "&f escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func float64ptrbitsptr(f *float64) *uint64 { // ERROR "leaking param: f to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return (*uint64)(unsafe.Pointer(f))
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func typesw(i interface{}) *int { // ERROR "leaking param: i to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
switch val := i.(type) {
|
|
|
|
case *int:
|
|
|
|
return val
|
|
|
|
case *int8:
|
2015-02-19 12:00:11 -07:00
|
|
|
v := int(*val) // ERROR "moved to heap: v$"
|
|
|
|
return &v // ERROR "&v escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func exprsw(i *int) *int { // ERROR "leaking param: i to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
switch j := i; *j + 110 {
|
|
|
|
case 12:
|
|
|
|
return j
|
|
|
|
case 42:
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
// assigning to an array element is like assigning to the array
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo60(i *int) *int { // ERROR "leaking param: i to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var a [12]*int
|
|
|
|
a[0] = i
|
|
|
|
return a[1]
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo60a(i *int) *int { // ERROR "foo60a i does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var a [12]*int
|
|
|
|
a[0] = i
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// assigning to a struct field is like assigning to the struct
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo61(i *int) *int { // ERROR "leaking param: i to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
type S struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
a, b *int
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
var s S
|
|
|
|
s.a = i
|
|
|
|
return s.b
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo61a(i *int) *int { // ERROR "foo61a i does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
type S struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
a, b *int
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
var s S
|
|
|
|
s.a = i
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// assigning to a struct field is like assigning to the struct but
|
|
|
|
// here this subtlety is lost, since s.a counts as an assignment to a
|
|
|
|
// track-losing dereference.
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo62(i *int) *int { // ERROR "leaking param: i$"
|
2011-08-24 11:07:08 -06:00
|
|
|
type S struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
a, b *int
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
2015-02-19 12:00:11 -07:00
|
|
|
s := new(S) // ERROR "foo62 new\(S\) does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
s.a = i
|
2011-08-28 10:05:00 -06:00
|
|
|
return nil // s.b
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2011-08-28 10:05:00 -06:00
|
|
|
type M interface {
|
|
|
|
M()
|
|
|
|
}
|
2011-08-24 11:07:08 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo63(m M) { // ERROR "foo63 m does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo64(m M) { // ERROR "leaking param: m$"
|
2011-08-24 11:07:08 -06:00
|
|
|
m.M()
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo64b(m M) { // ERROR "leaking param: m$"
|
2011-09-07 11:03:11 -06:00
|
|
|
defer m.M()
|
|
|
|
}
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
type MV int
|
2011-08-28 10:05:00 -06:00
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
func (MV) M() {}
|
|
|
|
|
|
|
|
func foo65() {
|
|
|
|
var mv MV
|
2015-02-19 12:00:11 -07:00
|
|
|
foo63(&mv) // ERROR "foo65 &mv does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo66() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var mv MV // ERROR "moved to heap: mv$"
|
|
|
|
foo64(&mv) // ERROR "&mv escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo67() {
|
|
|
|
var mv MV
|
2015-02-19 12:00:11 -07:00
|
|
|
foo63(mv) // ERROR "foo67 mv does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo68() {
|
|
|
|
var mv MV
|
2015-02-19 06:27:32 -07:00
|
|
|
// escapes but it's an int so irrelevant
|
2015-02-19 12:00:11 -07:00
|
|
|
foo64(mv) // ERROR "mv escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo69(m M) { // ERROR "leaking param: m$"
|
2011-08-24 11:07:08 -06:00
|
|
|
foo64(m)
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo70(mv1 *MV, m M) { // ERROR "leaking param: m$" "leaking param: mv1$"
|
|
|
|
m = mv1 // ERROR "mv1 escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
foo64(m)
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo71(x *int) []*int { // ERROR "leaking param: x$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var y []*int
|
|
|
|
y = append(y, x)
|
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo71a(x int) []*int { // ERROR "moved to heap: x$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var y []*int
|
2015-02-19 12:00:11 -07:00
|
|
|
y = append(y, &x) // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo72() {
|
|
|
|
var x int
|
|
|
|
var y [1]*int
|
2015-02-19 12:00:11 -07:00
|
|
|
y[0] = &x // ERROR "foo72 &x does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo72aa() [10]*int {
|
2015-02-19 12:00:11 -07:00
|
|
|
var x int // ERROR "moved to heap: x$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var y [10]*int
|
2015-02-19 12:00:11 -07:00
|
|
|
y[0] = &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo72a() {
|
|
|
|
var y [10]*int
|
|
|
|
for i := 0; i < 10; i++ {
|
2011-08-28 10:05:00 -06:00
|
|
|
// escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
x := i // ERROR "moved to heap: x$"
|
|
|
|
y[i] = &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo72b() [10]*int {
|
|
|
|
var y [10]*int
|
|
|
|
for i := 0; i < 10; i++ {
|
2015-02-19 12:00:11 -07:00
|
|
|
x := i // ERROR "moved to heap: x$"
|
|
|
|
y[i] = &x // ERROR "&x escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
|
|
|
// issue 2145
|
|
|
|
func foo73() {
|
2015-02-19 12:00:11 -07:00
|
|
|
s := []int{3, 2, 1} // ERROR "foo73 \[\]int literal does not escape$"
|
2015-01-19 12:59:58 -07:00
|
|
|
for _, v := range s {
|
|
|
|
vv := v
|
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
defer func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo731() {
|
2015-02-19 12:00:11 -07:00
|
|
|
s := []int{3, 2, 1} // ERROR "foo731 \[\]int literal does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
for _, v := range s {
|
2015-02-19 12:00:11 -07:00
|
|
|
vv := v // ERROR "moved to heap: vv$"
|
2011-08-28 10:05:00 -06:00
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
defer func() { // ERROR "func literal escapes to heap$"
|
|
|
|
vv = 42 // ERROR "&vv escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
2011-08-24 11:07:08 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo74() {
|
2015-02-19 12:00:11 -07:00
|
|
|
s := []int{3, 2, 1} // ERROR "foo74 \[\]int literal does not escape$"
|
2015-01-19 12:59:58 -07:00
|
|
|
for _, v := range s {
|
|
|
|
vv := v
|
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
fn := func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
|
|
|
}
|
|
|
|
defer fn()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo74a() {
|
2015-02-19 12:00:11 -07:00
|
|
|
s := []int{3, 2, 1} // ERROR "foo74a \[\]int literal does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
for _, v := range s {
|
2015-02-19 12:00:11 -07:00
|
|
|
vv := v // ERROR "moved to heap: vv$"
|
2011-08-28 10:05:00 -06:00
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
fn := func() { // ERROR "func literal escapes to heap$"
|
|
|
|
vv += 1 // ERROR "&vv escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
defer fn()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-31 14:23:37 -06:00
|
|
|
// issue 3975
|
|
|
|
func foo74b() {
|
2015-01-19 12:59:58 -07:00
|
|
|
var array [3]func()
|
2015-02-19 12:00:11 -07:00
|
|
|
s := []int{3, 2, 1} // ERROR "foo74b \[\]int literal does not escape$"
|
2015-01-19 12:59:58 -07:00
|
|
|
for i, v := range s {
|
|
|
|
vv := v
|
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
array[i] = func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo74c() {
|
2012-08-31 14:23:37 -06:00
|
|
|
var array [3]func()
|
2015-02-19 12:00:11 -07:00
|
|
|
s := []int{3, 2, 1} // ERROR "foo74c \[\]int literal does not escape$"
|
2012-08-31 14:23:37 -06:00
|
|
|
for i, v := range s {
|
2015-02-19 12:00:11 -07:00
|
|
|
vv := v // ERROR "moved to heap: vv$"
|
2012-08-31 14:23:37 -06:00
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
array[i] = func() { // ERROR "func literal escapes to heap$"
|
2015-05-27 05:31:56 -06:00
|
|
|
println(&vv) // ERROR "&vv escapes to heap$" "foo74c.func1 &vv does not escape$"
|
2012-08-31 14:23:37 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func myprint(y *int, x ...interface{}) *int { // ERROR "leaking param: y to result ~r2 level=0$" "myprint x does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func myprint1(y *int, x ...interface{}) *interface{} { // ERROR "leaking param: x to result ~r2 level=0$" "myprint1 y does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return &x[0] // ERROR "&x\[0\] escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo75(z *int) { // ERROR "foo75 z does not escape$"
|
2015-09-30 12:41:00 -06:00
|
|
|
myprint(z, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "foo75 ... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo75a(z *int) { // ERROR "foo75a z does not escape$"
|
2015-09-30 12:41:00 -06:00
|
|
|
myprint1(z, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "foo75a ... argument does not escape$"
|
cmd/gc: escape analysis to track flow of in to out parameters.
includes step 0: synthesize outparams, from 6600044
includes step 1,2: give outparams loopdepth 0 and verify unchanged results
generate esc:$mask tags, but still tie to sink if a param has mask != 0
from 6610054
adds final steps:
- have esccall generate n->escretval, a list of nodes the function results flow to
- use these in esccall and ORETURN/OAS2FUNC/and f(g())
- only tie parameters to sink if tag is absent, otherwise according to mask, tie them to escretval
R=rsc, bradfitz
CC=dave, gobot, golang-dev, iant, rsc
https://golang.org/cl/6741044
2012-10-29 06:38:21 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo75esc(z *int) { // ERROR "leaking param: z$"
|
2015-09-30 12:41:00 -06:00
|
|
|
gxx = myprint(z, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "foo75esc ... argument does not escape$"
|
cmd/gc: escape analysis to track flow of in to out parameters.
includes step 0: synthesize outparams, from 6600044
includes step 1,2: give outparams loopdepth 0 and verify unchanged results
generate esc:$mask tags, but still tie to sink if a param has mask != 0
from 6610054
adds final steps:
- have esccall generate n->escretval, a list of nodes the function results flow to
- use these in esccall and ORETURN/OAS2FUNC/and f(g())
- only tie parameters to sink if tag is absent, otherwise according to mask, tie them to escretval
R=rsc, bradfitz
CC=dave, gobot, golang-dev, iant, rsc
https://golang.org/cl/6741044
2012-10-29 06:38:21 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo75aesc(z *int) { // ERROR "foo75aesc z does not escape$"
|
2012-12-20 15:27:28 -07:00
|
|
|
var ppi **interface{} // assignments to pointer dereferences lose track
|
2015-02-19 12:00:11 -07:00
|
|
|
*ppi = myprint1(z, 1, 2, 3) // ERROR "... argument escapes to heap$" "1 escapes to heap$" "2 escapes to heap$" "3 escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo75aesc1(z *int) { // ERROR "foo75aesc1 z does not escape$"
|
|
|
|
sink = myprint1(z, 1, 2, 3) // ERROR "... argument escapes to heap$" "1 escapes to heap$" "2 escapes to heap$" "3 escapes to heap$" "myprint1\(z, 1, 2, 3\) escapes to heap$"
|
2015-02-19 07:54:55 -07:00
|
|
|
}
|
|
|
|
|
2015-09-30 12:41:00 -06:00
|
|
|
func foo76(z *int) { // ERROR "z does not escape"
|
|
|
|
myprint(nil, z) // ERROR "foo76 ... argument does not escape$" "z does not escape"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-09-30 12:41:00 -06:00
|
|
|
func foo76a(z *int) { // ERROR "z does not escape"
|
|
|
|
myprint1(nil, z) // ERROR "foo76a ... argument does not escape$" "z does not escape"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76b() {
|
2015-09-30 12:41:00 -06:00
|
|
|
myprint(nil, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "foo76b ... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76c() {
|
2015-09-30 12:41:00 -06:00
|
|
|
myprint1(nil, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "foo76c ... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76d() {
|
2015-09-30 12:41:00 -06:00
|
|
|
defer myprint(nil, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "foo76d ... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76e() {
|
2015-09-30 12:41:00 -06:00
|
|
|
defer myprint1(nil, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "foo76e ... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76f() {
|
|
|
|
for {
|
2011-08-28 10:05:00 -06:00
|
|
|
// TODO: This one really only escapes its scope, but we don't distinguish yet.
|
2015-02-19 12:00:11 -07:00
|
|
|
defer myprint(nil, 1, 2, 3) // ERROR "... argument escapes to heap$" "1 escapes to heap$" "2 escapes to heap$" "3 escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo76g() {
|
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
defer myprint1(nil, 1, 2, 3) // ERROR "... argument escapes to heap$" "1 escapes to heap$" "2 escapes to heap$" "3 escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo77(z []interface{}) { // ERROR "foo77 z does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
myprint(nil, z...) // z does not escape
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo77a(z []interface{}) { // ERROR "foo77a z does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
myprint1(nil, z...)
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo77b(z []interface{}) { // ERROR "leaking param: z$"
|
cmd/gc: escape analysis to track flow of in to out parameters.
includes step 0: synthesize outparams, from 6600044
includes step 1,2: give outparams loopdepth 0 and verify unchanged results
generate esc:$mask tags, but still tie to sink if a param has mask != 0
from 6610054
adds final steps:
- have esccall generate n->escretval, a list of nodes the function results flow to
- use these in esccall and ORETURN/OAS2FUNC/and f(g())
- only tie parameters to sink if tag is absent, otherwise according to mask, tie them to escretval
R=rsc, bradfitz
CC=dave, gobot, golang-dev, iant, rsc
https://golang.org/cl/6741044
2012-10-29 06:38:21 -06:00
|
|
|
var ppi **interface{}
|
|
|
|
*ppi = myprint1(nil, z...)
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo77c(z []interface{}) { // ERROR "leaking param: z$"
|
|
|
|
sink = myprint1(nil, z...) // ERROR "myprint1\(nil, z...\) escapes to heap$"
|
2015-02-19 07:54:55 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func dotdotdot() {
|
2015-09-30 12:41:00 -06:00
|
|
|
i := 0
|
|
|
|
myprint(nil, &i) // ERROR "&i does not escape" "dotdotdot ... argument does not escape$"
|
2015-02-19 07:54:55 -07:00
|
|
|
|
2015-09-30 12:41:00 -06:00
|
|
|
j := 0
|
|
|
|
myprint1(nil, &j) // ERROR "&j does not escape" "dotdotdot ... argument does not escape$"
|
2015-02-19 07:54:55 -07:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo78(z int) *int { // ERROR "moved to heap: z$"
|
|
|
|
return &z // ERROR "&z escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo78a(z int) *int { // ERROR "moved to heap: z$"
|
|
|
|
y := &z // ERROR "&z escapes to heap$"
|
|
|
|
x := &y // ERROR "foo78a &y does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return *x // really return y
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo79() *int {
|
2015-02-19 12:00:11 -07:00
|
|
|
return new(int) // ERROR "new\(int\) escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo80() *int {
|
|
|
|
var z *int
|
|
|
|
for {
|
2011-08-28 10:05:00 -06:00
|
|
|
// Really just escapes its scope but we don't distinguish
|
2015-02-19 12:00:11 -07:00
|
|
|
z = new(int) // ERROR "new\(int\) escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
_ = z
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo81() *int {
|
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
z := new(int) // ERROR "foo81 new\(int\) does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
_ = z
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func tee(p *int) (x, y *int) { return p, p } // ERROR "leaking param: p to result x level=0$" "leaking param: p to result y level=0$"
|
2012-12-20 15:27:28 -07:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func noop(x, y *int) {} // ERROR "noop x does not escape$" "noop y does not escape$"
|
2012-12-20 15:27:28 -07:00
|
|
|
|
|
|
|
func foo82() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var x, y, z int // ERROR "moved to heap: x$" "moved to heap: y$" "moved to heap: z$"
|
|
|
|
go noop(tee(&z)) // ERROR "&z escapes to heap$"
|
|
|
|
go noop(&x, &y) // ERROR "&x escapes to heap$" "&y escapes to heap$"
|
2012-12-20 15:27:28 -07:00
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
var u, v, w int // ERROR "moved to heap: u$" "moved to heap: v$" "moved to heap: w$"
|
|
|
|
defer noop(tee(&u)) // ERROR "&u escapes to heap$"
|
|
|
|
defer noop(&v, &w) // ERROR "&v escapes to heap$" "&w escapes to heap$"
|
2012-12-20 15:27:28 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
type Fooer interface {
|
|
|
|
Foo()
|
|
|
|
}
|
|
|
|
|
|
|
|
type LimitedFooer struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
Fooer
|
|
|
|
N int64
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func LimitFooer(r Fooer, n int64) Fooer { // ERROR "leaking param: r to result ~r2 level=-1$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return &LimitedFooer{r, n} // ERROR "&LimitedFooer literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo90(x *int) map[*int]*int { // ERROR "leaking param: x$"
|
|
|
|
return map[*int]*int{nil: x} // ERROR "map\[\*int\]\*int literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo91(x *int) map[*int]*int { // ERROR "leaking param: x$"
|
|
|
|
return map[*int]*int{x: nil} // ERROR "map\[\*int\]\*int literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo92(x *int) [2]*int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return [2]*int{x, nil}
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2011-08-25 07:26:13 -06:00
|
|
|
// does not leak c
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo93(c chan *int) *int { // ERROR "foo93 c does not escape$"
|
2011-08-25 07:26:13 -06:00
|
|
|
for v := range c {
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// does not leak m
|
2015-05-15 10:19:07 -06:00
|
|
|
func foo94(m map[*int]*int, b bool) *int { // ERROR "leaking param: m to result ~r2 level=1"
|
2011-08-25 07:26:13 -06:00
|
|
|
for k, v := range m {
|
|
|
|
if b {
|
|
|
|
return k
|
|
|
|
}
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak x
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo95(m map[*int]*int, x *int) { // ERROR "foo95 m does not escape$" "leaking param: x$"
|
2011-08-25 07:26:13 -06:00
|
|
|
m[x] = x
|
|
|
|
}
|
|
|
|
|
2015-05-15 10:19:07 -06:00
|
|
|
// does not leak m but does leak content
|
|
|
|
func foo96(m []*int) *int { // ERROR "leaking param: m to result ~r1 level=1"
|
2011-08-25 07:26:13 -06:00
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak m
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo97(m [1]*int) *int { // ERROR "leaking param: m to result ~r1 level=0$"
|
2011-08-25 07:26:13 -06:00
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
|
|
|
// does not leak m
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo98(m map[int]*int) *int { // ERROR "foo98 m does not escape$"
|
2011-08-25 07:26:13 -06:00
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak m
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo99(m *[1]*int) []*int { // ERROR "leaking param: m to result ~r1 level=0$"
|
2011-08-25 07:26:13 -06:00
|
|
|
return m[:]
|
|
|
|
}
|
|
|
|
|
|
|
|
// does not leak m
|
2015-05-15 10:19:07 -06:00
|
|
|
func foo100(m []*int) *int { // ERROR "leaking param: m to result ~r1 level=1"
|
2011-08-25 07:26:13 -06:00
|
|
|
for _, v := range m {
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak m
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo101(m [1]*int) *int { // ERROR "leaking param: m to result ~r1 level=0$"
|
2011-08-25 07:26:13 -06:00
|
|
|
for _, v := range m {
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2011-08-28 10:05:00 -06:00
|
|
|
// does not leak m
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo101a(m [1]*int) *int { // ERROR "foo101a m does not escape$"
|
|
|
|
for i := range m { // ERROR "moved to heap: i$"
|
|
|
|
return &i // ERROR "&i escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2011-08-25 07:26:13 -06:00
|
|
|
// does leak x
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo102(m []*int, x *int) { // ERROR "foo102 m does not escape$" "leaking param: x$"
|
2011-08-25 07:26:13 -06:00
|
|
|
m[0] = x
|
|
|
|
}
|
|
|
|
|
|
|
|
// does not leak x
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo103(m [1]*int, x *int) { // ERROR "foo103 m does not escape$" "foo103 x does not escape$"
|
2011-08-25 07:26:13 -06:00
|
|
|
m[0] = x
|
|
|
|
}
|
|
|
|
|
|
|
|
var y []*int
|
|
|
|
|
2015-06-24 15:31:57 -06:00
|
|
|
// does not leak x but does leak content
|
|
|
|
func foo104(x []*int) { // ERROR "leaking param content: x"
|
2011-08-25 07:26:13 -06:00
|
|
|
copy(y, x)
|
|
|
|
}
|
|
|
|
|
2015-05-15 10:19:07 -06:00
|
|
|
// does not leak x but does leak content
|
|
|
|
func foo105(x []*int) { // ERROR "leaking param content: x"
|
2011-08-25 07:26:13 -06:00
|
|
|
_ = append(y, x...)
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak x
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo106(x *int) { // ERROR "leaking param: x$"
|
2011-08-25 07:26:13 -06:00
|
|
|
_ = append(y, x)
|
|
|
|
}
|
2011-08-28 10:05:00 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo107(x *int) map[*int]*int { // ERROR "leaking param: x$"
|
|
|
|
return map[*int]*int{x: nil} // ERROR "map\[\*int\]\*int literal escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo108(x *int) map[*int]*int { // ERROR "leaking param: x$"
|
|
|
|
return map[*int]*int{nil: x} // ERROR "map\[\*int\]\*int literal escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo109(x *int) *int { // ERROR "leaking param: x$"
|
|
|
|
m := map[*int]*int{x: nil} // ERROR "foo109 map\[\*int\]\*int literal does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
for k, _ := range m {
|
|
|
|
return k
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo110(x *int) *int { // ERROR "leaking param: x$"
|
|
|
|
m := map[*int]*int{nil: x} // ERROR "foo110 map\[\*int\]\*int literal does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return m[nil]
|
|
|
|
}
|
|
|
|
|
2015-05-15 10:19:07 -06:00
|
|
|
func foo111(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0"
|
2015-02-19 12:00:11 -07:00
|
|
|
m := []*int{x} // ERROR "foo111 \[\]\*int literal does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo112(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2011-08-28 10:05:00 -06:00
|
|
|
m := [1]*int{x}
|
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo113(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2011-08-28 10:05:00 -06:00
|
|
|
m := Bar{ii: x}
|
|
|
|
return m.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo114(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2015-02-19 12:00:11 -07:00
|
|
|
m := &Bar{ii: x} // ERROR "foo114 &Bar literal does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return m.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo115(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return (*int)(unsafe.Pointer(uintptr(unsafe.Pointer(x)) + 1))
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo116(b bool) *int {
|
|
|
|
if b {
|
2015-02-19 12:00:11 -07:00
|
|
|
x := 1 // ERROR "moved to heap: x$"
|
|
|
|
return &x // ERROR "&x escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
} else {
|
2015-02-19 12:00:11 -07:00
|
|
|
y := 1 // ERROR "moved to heap: y$"
|
|
|
|
return &y // ERROR "&y escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo117(unknown func(interface{})) { // ERROR "foo117 unknown does not escape$"
|
|
|
|
x := 1 // ERROR "moved to heap: x$"
|
|
|
|
unknown(&x) // ERROR "&x escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo118(unknown func(*int)) { // ERROR "foo118 unknown does not escape$"
|
|
|
|
x := 1 // ERROR "moved to heap: x$"
|
|
|
|
unknown(&x) // ERROR "&x escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
2011-08-28 21:29:34 -06:00
|
|
|
|
|
|
|
func external(*int)
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo119(x *int) { // ERROR "leaking param: x$"
|
2011-08-28 21:29:34 -06:00
|
|
|
external(x)
|
|
|
|
}
|
2011-09-01 11:44:46 -06:00
|
|
|
|
|
|
|
func foo120() {
|
|
|
|
// formerly exponential time analysis
|
|
|
|
L1:
|
|
|
|
L2:
|
|
|
|
L3:
|
|
|
|
L4:
|
|
|
|
L5:
|
|
|
|
L6:
|
|
|
|
L7:
|
|
|
|
L8:
|
|
|
|
L9:
|
|
|
|
L10:
|
|
|
|
L11:
|
|
|
|
L12:
|
|
|
|
L13:
|
|
|
|
L14:
|
|
|
|
L15:
|
|
|
|
L16:
|
|
|
|
L17:
|
|
|
|
L18:
|
|
|
|
L19:
|
|
|
|
L20:
|
|
|
|
L21:
|
|
|
|
L22:
|
|
|
|
L23:
|
|
|
|
L24:
|
|
|
|
L25:
|
|
|
|
L26:
|
|
|
|
L27:
|
|
|
|
L28:
|
|
|
|
L29:
|
|
|
|
L30:
|
|
|
|
L31:
|
|
|
|
L32:
|
|
|
|
L33:
|
|
|
|
L34:
|
|
|
|
L35:
|
|
|
|
L36:
|
|
|
|
L37:
|
|
|
|
L38:
|
|
|
|
L39:
|
|
|
|
L40:
|
|
|
|
L41:
|
|
|
|
L42:
|
|
|
|
L43:
|
|
|
|
L44:
|
|
|
|
L45:
|
|
|
|
L46:
|
|
|
|
L47:
|
|
|
|
L48:
|
|
|
|
L49:
|
|
|
|
L50:
|
|
|
|
L51:
|
|
|
|
L52:
|
|
|
|
L53:
|
|
|
|
L54:
|
|
|
|
L55:
|
|
|
|
L56:
|
|
|
|
L57:
|
|
|
|
L58:
|
|
|
|
L59:
|
|
|
|
L60:
|
|
|
|
L61:
|
|
|
|
L62:
|
|
|
|
L63:
|
|
|
|
L64:
|
|
|
|
L65:
|
|
|
|
L66:
|
|
|
|
L67:
|
|
|
|
L68:
|
|
|
|
L69:
|
|
|
|
L70:
|
|
|
|
L71:
|
|
|
|
L72:
|
|
|
|
L73:
|
|
|
|
L74:
|
|
|
|
L75:
|
|
|
|
L76:
|
|
|
|
L77:
|
|
|
|
L78:
|
|
|
|
L79:
|
|
|
|
L80:
|
|
|
|
L81:
|
|
|
|
L82:
|
|
|
|
L83:
|
|
|
|
L84:
|
|
|
|
L85:
|
|
|
|
L86:
|
|
|
|
L87:
|
|
|
|
L88:
|
|
|
|
L89:
|
|
|
|
L90:
|
|
|
|
L91:
|
|
|
|
L92:
|
|
|
|
L93:
|
|
|
|
L94:
|
|
|
|
L95:
|
|
|
|
L96:
|
|
|
|
L97:
|
|
|
|
L98:
|
|
|
|
L99:
|
|
|
|
L100:
|
|
|
|
// use the labels to silence compiler errors
|
|
|
|
goto L1
|
|
|
|
goto L2
|
|
|
|
goto L3
|
|
|
|
goto L4
|
|
|
|
goto L5
|
|
|
|
goto L6
|
|
|
|
goto L7
|
|
|
|
goto L8
|
|
|
|
goto L9
|
|
|
|
goto L10
|
|
|
|
goto L11
|
|
|
|
goto L12
|
|
|
|
goto L13
|
|
|
|
goto L14
|
|
|
|
goto L15
|
|
|
|
goto L16
|
|
|
|
goto L17
|
|
|
|
goto L18
|
|
|
|
goto L19
|
|
|
|
goto L20
|
|
|
|
goto L21
|
|
|
|
goto L22
|
|
|
|
goto L23
|
|
|
|
goto L24
|
|
|
|
goto L25
|
|
|
|
goto L26
|
|
|
|
goto L27
|
|
|
|
goto L28
|
|
|
|
goto L29
|
|
|
|
goto L30
|
|
|
|
goto L31
|
|
|
|
goto L32
|
|
|
|
goto L33
|
|
|
|
goto L34
|
|
|
|
goto L35
|
|
|
|
goto L36
|
|
|
|
goto L37
|
|
|
|
goto L38
|
|
|
|
goto L39
|
|
|
|
goto L40
|
|
|
|
goto L41
|
|
|
|
goto L42
|
|
|
|
goto L43
|
|
|
|
goto L44
|
|
|
|
goto L45
|
|
|
|
goto L46
|
|
|
|
goto L47
|
|
|
|
goto L48
|
|
|
|
goto L49
|
|
|
|
goto L50
|
|
|
|
goto L51
|
|
|
|
goto L52
|
|
|
|
goto L53
|
|
|
|
goto L54
|
|
|
|
goto L55
|
|
|
|
goto L56
|
|
|
|
goto L57
|
|
|
|
goto L58
|
|
|
|
goto L59
|
|
|
|
goto L60
|
|
|
|
goto L61
|
|
|
|
goto L62
|
|
|
|
goto L63
|
|
|
|
goto L64
|
|
|
|
goto L65
|
|
|
|
goto L66
|
|
|
|
goto L67
|
|
|
|
goto L68
|
|
|
|
goto L69
|
|
|
|
goto L70
|
|
|
|
goto L71
|
|
|
|
goto L72
|
|
|
|
goto L73
|
|
|
|
goto L74
|
|
|
|
goto L75
|
|
|
|
goto L76
|
|
|
|
goto L77
|
|
|
|
goto L78
|
|
|
|
goto L79
|
|
|
|
goto L80
|
|
|
|
goto L81
|
|
|
|
goto L82
|
|
|
|
goto L83
|
|
|
|
goto L84
|
|
|
|
goto L85
|
|
|
|
goto L86
|
|
|
|
goto L87
|
|
|
|
goto L88
|
|
|
|
goto L89
|
|
|
|
goto L90
|
|
|
|
goto L91
|
|
|
|
goto L92
|
|
|
|
goto L93
|
|
|
|
goto L94
|
|
|
|
goto L95
|
|
|
|
goto L96
|
|
|
|
goto L97
|
|
|
|
goto L98
|
|
|
|
goto L99
|
|
|
|
goto L100
|
|
|
|
}
|
2011-11-01 09:02:43 -06:00
|
|
|
|
|
|
|
func foo121() {
|
|
|
|
for i := 0; i < 10; i++ {
|
2015-02-19 12:00:11 -07:00
|
|
|
defer myprint(nil, i) // ERROR "... argument escapes to heap$" "i escapes to heap$"
|
|
|
|
go myprint(nil, i) // ERROR "... argument escapes to heap$" "i escapes to heap$"
|
2011-11-01 09:02:43 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// same as foo121 but check across import
|
|
|
|
func foo121b() {
|
|
|
|
for i := 0; i < 10; i++ {
|
2015-02-19 12:00:11 -07:00
|
|
|
defer fmt.Printf("%d", i) // ERROR "... argument escapes to heap$" "i escapes to heap$"
|
|
|
|
go fmt.Printf("%d", i) // ERROR "... argument escapes to heap$" "i escapes to heap$"
|
2011-11-01 09:02:43 -06:00
|
|
|
}
|
|
|
|
}
|
2011-12-15 09:35:59 -07:00
|
|
|
|
|
|
|
// a harmless forward jump
|
|
|
|
func foo122() {
|
|
|
|
var i *int
|
|
|
|
|
|
|
|
goto L1
|
|
|
|
L1:
|
2015-02-19 12:00:11 -07:00
|
|
|
i = new(int) // ERROR "foo122 new\(int\) does not escape$"
|
2011-12-15 09:35:59 -07:00
|
|
|
_ = i
|
|
|
|
}
|
|
|
|
|
|
|
|
// a backward jump, increases loopdepth
|
|
|
|
func foo123() {
|
|
|
|
var i *int
|
|
|
|
|
|
|
|
L1:
|
2015-02-19 12:00:11 -07:00
|
|
|
i = new(int) // ERROR "new\(int\) escapes to heap$"
|
2011-12-15 09:35:59 -07:00
|
|
|
|
|
|
|
goto L1
|
|
|
|
_ = i
|
2012-01-12 04:08:40 -07:00
|
|
|
}
|
2012-04-23 13:39:01 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo124(x **int) { // ERROR "foo124 x does not escape$"
|
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$"
|
|
|
|
func() { // ERROR "foo124 func literal does not escape$"
|
|
|
|
*x = p // ERROR "leaking closure reference p$"
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo125(ch chan *int) { // ERROR "foo125 ch does not escape$"
|
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$"
|
|
|
|
func() { // ERROR "foo125 func literal does not escape$"
|
|
|
|
ch <- p // ERROR "leaking closure reference p$"
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo126() {
|
2012-12-20 15:27:28 -07:00
|
|
|
var px *int // loopdepth 0
|
2012-04-23 13:39:01 -06:00
|
|
|
for {
|
|
|
|
// loopdepth 1
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
func() { // ERROR "foo126 func literal does not escape$"
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 14:44:20 -07:00
|
|
|
px = &i // ERROR "&i escapes to heap$" "leaking closure reference i"
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
2013-09-17 16:24:54 -06:00
|
|
|
_ = px
|
2012-04-23 13:39:01 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
var px *int
|
|
|
|
|
|
|
|
func foo127() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$"
|
2012-04-23 13:39:01 -06:00
|
|
|
q := p
|
|
|
|
px = q
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo128() {
|
|
|
|
var i int
|
2015-02-19 12:00:11 -07:00
|
|
|
p := &i // ERROR "foo128 &i does not escape$"
|
2012-04-23 13:39:01 -06:00
|
|
|
q := p
|
|
|
|
_ = q
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo129() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$"
|
|
|
|
func() { // ERROR "foo129 func literal does not escape$"
|
|
|
|
q := p // ERROR "leaking closure reference p$"
|
2015-05-27 05:31:56 -06:00
|
|
|
func() { // ERROR "foo129.func1 func literal does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
r := q // ERROR "leaking closure reference q$"
|
2012-04-23 13:39:01 -06:00
|
|
|
px = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo130() {
|
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
func() { // ERROR "foo130 func literal does not escape$"
|
|
|
|
px = &i // ERROR "&i escapes to heap$" "leaking closure reference i$"
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo131() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
func() { // ERROR "foo131 func literal does not escape$"
|
|
|
|
px = &i // ERROR "&i escapes to heap$" "leaking closure reference i$"
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo132() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
go func() { // ERROR "func literal escapes to heap$"
|
|
|
|
px = &i // ERROR "&i escapes to heap$" "leaking closure reference i$"
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo133() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
defer func() { // ERROR "foo133 func literal does not escape$"
|
|
|
|
px = &i // ERROR "&i escapes to heap$" "leaking closure reference i$"
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo134() {
|
|
|
|
var i int
|
2015-02-19 12:00:11 -07:00
|
|
|
p := &i // ERROR "foo134 &i does not escape$"
|
|
|
|
func() { // ERROR "foo134 func literal does not escape$"
|
2012-04-23 13:39:01 -06:00
|
|
|
q := p
|
2015-05-27 05:31:56 -06:00
|
|
|
func() { // ERROR "foo134.func1 func literal does not escape$"
|
2012-04-23 13:39:01 -06:00
|
|
|
r := q
|
|
|
|
_ = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo135() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$"
|
|
|
|
go func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
q := p
|
2015-05-27 05:31:56 -06:00
|
|
|
func() { // ERROR "foo135.func1 func literal does not escape$"
|
2012-04-23 13:39:01 -06:00
|
|
|
r := q
|
|
|
|
_ = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo136() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$"
|
|
|
|
go func() { // ERROR "func literal escapes to heap$"
|
|
|
|
q := p // ERROR "leaking closure reference p$"
|
2015-05-27 05:31:56 -06:00
|
|
|
func() { // ERROR "foo136.func1 func literal does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
r := q // ERROR "leaking closure reference q$"
|
2012-04-23 13:39:01 -06:00
|
|
|
px = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo137() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$"
|
|
|
|
func() { // ERROR "foo137 func literal does not escape$"
|
|
|
|
q := p // ERROR "leaking closure reference p$"
|
|
|
|
go func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
r := q
|
2012-04-23 13:39:01 -06:00
|
|
|
_ = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
2012-09-24 13:53:12 -06:00
|
|
|
|
|
|
|
func foo138() *byte {
|
|
|
|
type T struct {
|
|
|
|
x [1]byte
|
|
|
|
}
|
2015-02-19 12:00:11 -07:00
|
|
|
t := new(T) // ERROR "new\(T\) escapes to heap$"
|
|
|
|
return &t.x[0] // ERROR "&t.x\[0\] escapes to heap$"
|
2012-09-24 13:53:12 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo139() *byte {
|
|
|
|
type T struct {
|
|
|
|
x struct {
|
|
|
|
y byte
|
|
|
|
}
|
|
|
|
}
|
2015-02-19 12:00:11 -07:00
|
|
|
t := new(T) // ERROR "new\(T\) escapes to heap$"
|
|
|
|
return &t.x.y // ERROR "&t.x.y escapes to heap$"
|
2012-09-24 13:53:12 -06:00
|
|
|
}
|
2013-02-04 20:48:31 -07:00
|
|
|
|
|
|
|
// issue 4751
|
|
|
|
func foo140() interface{} {
|
|
|
|
type T struct {
|
|
|
|
X string
|
|
|
|
}
|
|
|
|
type U struct {
|
|
|
|
X string
|
|
|
|
T *T
|
|
|
|
}
|
2015-02-19 12:00:11 -07:00
|
|
|
t := &T{} // ERROR "&T literal escapes to heap$"
|
|
|
|
return U{ // ERROR "U literal escapes to heap$"
|
2013-02-04 20:48:31 -07:00
|
|
|
X: t.X,
|
|
|
|
T: t,
|
|
|
|
}
|
|
|
|
}
|
2013-02-05 05:00:38 -07:00
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
|
|
|
func F1([]byte)
|
|
|
|
|
|
|
|
func F2([]byte)
|
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func F3(x []byte) // ERROR "F3 x does not escape$"
|
2013-02-05 05:00:38 -07:00
|
|
|
|
|
|
|
func F4(x []byte)
|
|
|
|
|
|
|
|
func G() {
|
|
|
|
var buf1 [10]byte
|
2015-02-19 12:00:11 -07:00
|
|
|
F1(buf1[:]) // ERROR "G buf1 does not escape$"
|
2014-05-09 13:40:45 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
var buf2 [10]byte // ERROR "moved to heap: buf2$"
|
|
|
|
F2(buf2[:]) // ERROR "buf2 escapes to heap$"
|
2013-02-05 05:00:38 -07:00
|
|
|
|
|
|
|
var buf3 [10]byte
|
2015-02-19 12:00:11 -07:00
|
|
|
F3(buf3[:]) // ERROR "G buf3 does not escape$"
|
2014-05-09 13:40:45 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
var buf4 [10]byte // ERROR "moved to heap: buf4$"
|
|
|
|
F4(buf4[:]) // ERROR "buf4 escapes to heap$"
|
2013-02-05 05:00:38 -07:00
|
|
|
}
|
2013-03-20 21:53:27 -06:00
|
|
|
|
|
|
|
type Tm struct {
|
|
|
|
x int
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (t *Tm) M() { // ERROR "\(\*Tm\).M t does not escape$"
|
2013-03-20 21:53:27 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo141() {
|
|
|
|
var f func()
|
2014-05-09 13:40:45 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
t := new(Tm) // ERROR "new\(Tm\) escapes to heap$"
|
|
|
|
f = t.M // ERROR "foo141 t.M does not escape$"
|
2013-03-20 21:53:27 -06:00
|
|
|
_ = f
|
|
|
|
}
|
|
|
|
|
|
|
|
var gf func()
|
|
|
|
|
|
|
|
func foo142() {
|
2015-02-19 12:00:11 -07:00
|
|
|
t := new(Tm) // ERROR "new\(Tm\) escapes to heap$"
|
|
|
|
gf = t.M // ERROR "t.M escapes to heap$"
|
2013-03-20 21:53:27 -06:00
|
|
|
}
|
2013-05-22 14:45:38 -06:00
|
|
|
|
|
|
|
// issue 3888.
|
|
|
|
func foo143() {
|
|
|
|
for i := 0; i < 1000; i++ {
|
2015-02-19 12:00:11 -07:00
|
|
|
func() { // ERROR "foo143 func literal does not escape$"
|
2013-05-22 14:45:38 -06:00
|
|
|
for i := 0; i < 1; i++ {
|
|
|
|
var t Tm
|
2015-05-27 05:31:56 -06:00
|
|
|
t.M() // ERROR "foo143.func1 t does not escape$"
|
2013-05-22 14:45:38 -06:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
}
|
2013-06-25 15:28:49 -06:00
|
|
|
|
|
|
|
// issue 5773
|
|
|
|
// Check that annotations take effect regardless of whether they
|
|
|
|
// are before or after the use in the source code.
|
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
|
|
|
func foo144a(*int)
|
|
|
|
|
|
|
|
func foo144() {
|
|
|
|
var x int
|
2015-02-19 12:00:11 -07:00
|
|
|
foo144a(&x) // ERROR "foo144 &x does not escape$"
|
2013-06-25 15:28:49 -06:00
|
|
|
var y int
|
2015-02-19 12:00:11 -07:00
|
|
|
foo144b(&y) // ERROR "foo144 &y does not escape$"
|
2013-06-25 15:28:49 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
|
|
|
func foo144b(*int)
|
2014-02-13 12:04:43 -07:00
|
|
|
|
|
|
|
// issue 7313: for loop init should not be treated as "in loop"
|
|
|
|
|
|
|
|
type List struct {
|
|
|
|
Next *List
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo145(l List) { // ERROR "foo145 l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
var p *List
|
2015-02-19 12:00:11 -07:00
|
|
|
for p = &l; p.Next != nil; p = p.Next { // ERROR "foo145 &l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo146(l List) { // ERROR "foo146 l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
var p *List
|
2015-02-19 12:00:11 -07:00
|
|
|
p = &l // ERROR "foo146 &l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
for ; p.Next != nil; p = p.Next {
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo147(l List) { // ERROR "foo147 l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
var p *List
|
2015-02-19 12:00:11 -07:00
|
|
|
p = &l // ERROR "foo147 &l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
for p.Next != nil {
|
|
|
|
p = p.Next
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo148(l List) { // ERROR "foo148 l does not escape$"
|
|
|
|
for p := &l; p.Next != nil; p = p.Next { // ERROR "foo148 &l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
}
|
|
|
|
}
|
2014-02-13 17:59:09 -07:00
|
|
|
|
|
|
|
// related: address of variable should have depth of variable, not of loop
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo149(l List) { // ERROR "foo149 l does not escape$"
|
2014-02-13 17:59:09 -07:00
|
|
|
var p *List
|
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
for p = &l; p.Next != nil; p = p.Next { // ERROR "foo149 &l does not escape$"
|
2014-02-13 17:59:09 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2014-05-09 13:40:45 -06:00
|
|
|
|
|
|
|
// issue 7934: missed ... if element type had no pointers
|
|
|
|
|
|
|
|
var save150 []byte
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo150(x ...byte) { // ERROR "leaking param: x$"
|
2014-05-09 13:40:45 -06:00
|
|
|
save150 = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func bar150() {
|
2015-02-19 12:00:11 -07:00
|
|
|
foo150(1, 2, 3) // ERROR "... argument escapes to heap$"
|
2014-05-09 13:40:45 -06:00
|
|
|
}
|
2014-05-12 12:45:05 -06:00
|
|
|
|
|
|
|
// issue 7931: bad handling of slice of array
|
|
|
|
|
|
|
|
var save151 *int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo151(x *int) { // ERROR "leaking param: x$"
|
2014-05-12 12:45:05 -06:00
|
|
|
save151 = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func bar151() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var a [64]int // ERROR "moved to heap: a$"
|
2014-05-12 12:45:05 -06:00
|
|
|
a[4] = 101
|
2015-02-19 12:00:11 -07:00
|
|
|
foo151(&(&a)[4:8][0]) // ERROR "&\(&a\)\[4:8\]\[0\] escapes to heap$" "&a escapes to heap$"
|
2014-05-12 12:45:05 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func bar151b() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var a [10]int // ERROR "moved to heap: a$"
|
|
|
|
b := a[:] // ERROR "a escapes to heap$"
|
|
|
|
foo151(&b[4:8][0]) // ERROR "&b\[4:8\]\[0\] escapes to heap$"
|
2014-05-12 12:45:05 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func bar151c() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var a [64]int // ERROR "moved to heap: a$"
|
2014-05-12 12:45:05 -06:00
|
|
|
a[4] = 101
|
2015-02-19 12:00:11 -07:00
|
|
|
foo151(&(&a)[4:8:8][0]) // ERROR "&\(&a\)\[4:8:8\]\[0\] escapes to heap$" "&a escapes to heap$"
|
2014-05-12 12:45:05 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func bar151d() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var a [10]int // ERROR "moved to heap: a$"
|
|
|
|
b := a[:] // ERROR "a escapes to heap$"
|
|
|
|
foo151(&b[4:8:8][0]) // ERROR "&b\[4:8:8\]\[0\] escapes to heap$"
|
2014-05-12 12:45:05 -06:00
|
|
|
}
|
cmd/gc: fix escape analysis of func returning indirect of parameter
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes #8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
2014-06-03 09:35:59 -06:00
|
|
|
|
|
|
|
// issue 8120
|
|
|
|
|
|
|
|
type U struct {
|
|
|
|
s *string
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (u *U) String() *string { // ERROR "leaking param: u to result ~r0 level=1$"
|
cmd/gc: fix escape analysis of func returning indirect of parameter
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes #8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
2014-06-03 09:35:59 -06:00
|
|
|
return u.s
|
|
|
|
}
|
|
|
|
|
|
|
|
type V struct {
|
|
|
|
s *string
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
// BAD -- level of leak ought to be 0
|
|
|
|
func NewV(u U) *V { // ERROR "leaking param: u to result ~r1 level=-1"
|
|
|
|
return &V{u.String()} // ERROR "&V literal escapes to heap$" "NewV u does not escape"
|
cmd/gc: fix escape analysis of func returning indirect of parameter
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes #8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
2014-06-03 09:35:59 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo152() {
|
2015-02-19 12:00:11 -07:00
|
|
|
a := "a" // ERROR "moved to heap: a$"
|
|
|
|
u := U{&a} // ERROR "&a escapes to heap$"
|
cmd/gc: fix escape analysis of func returning indirect of parameter
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes #8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
2014-06-03 09:35:59 -06:00
|
|
|
v := NewV(u)
|
|
|
|
println(v)
|
|
|
|
}
|
2014-06-11 09:48:47 -06:00
|
|
|
|
|
|
|
// issue 8176 - &x in type switch body not marked as escaping
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo153(v interface{}) *int { // ERROR "leaking param: v to result ~r1 level=-1$"
|
2014-06-11 09:48:47 -06:00
|
|
|
switch x := v.(type) {
|
2015-02-19 12:00:11 -07:00
|
|
|
case int: // ERROR "moved to heap: x$"
|
|
|
|
return &x // ERROR "&x escapes to heap$"
|
2014-06-11 09:48:47 -06:00
|
|
|
}
|
|
|
|
panic(0)
|
|
|
|
}
|
2014-06-11 12:21:06 -06:00
|
|
|
|
|
|
|
// issue 8185 - &result escaping into result
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func f() (x int, y *int) { // ERROR "moved to heap: x$"
|
|
|
|
y = &x // ERROR "&x escapes to heap$"
|
2014-06-11 12:21:06 -06:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func g() (x interface{}) { // ERROR "moved to heap: x$"
|
|
|
|
x = &x // ERROR "&x escapes to heap$"
|
2014-06-11 12:21:06 -06:00
|
|
|
return
|
|
|
|
}
|
2015-01-19 13:46:22 -07:00
|
|
|
|
|
|
|
var sink interface{}
|
|
|
|
|
|
|
|
type Lit struct {
|
|
|
|
p *int
|
|
|
|
}
|
|
|
|
|
|
|
|
func ptrlitNoescape() {
|
|
|
|
// Both literal and element do not escape.
|
|
|
|
i := 0
|
2015-02-19 12:00:11 -07:00
|
|
|
x := &Lit{&i} // ERROR "ptrlitNoescape &Lit literal does not escape$" "ptrlitNoescape &i does not escape$"
|
2015-01-19 13:46:22 -07:00
|
|
|
_ = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func ptrlitNoEscape2() {
|
|
|
|
// Literal does not escape, but element does.
|
2015-02-19 12:00:11 -07:00
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
x := &Lit{&i} // ERROR "&i escapes to heap$" "ptrlitNoEscape2 &Lit literal does not escape$"
|
|
|
|
sink = *x // ERROR "\*x escapes to heap$"
|
2015-01-19 13:46:22 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func ptrlitEscape() {
|
|
|
|
// Both literal and element escape.
|
2015-02-19 12:00:11 -07:00
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
x := &Lit{&i} // ERROR "&Lit literal escapes to heap$" "&i escapes to heap$"
|
|
|
|
sink = x // ERROR "x escapes to heap$"
|
2015-01-19 13:46:22 -07:00
|
|
|
}
|
2015-01-16 13:30:35 -07:00
|
|
|
|
|
|
|
// self-assignments
|
|
|
|
|
|
|
|
type Buffer struct {
|
|
|
|
arr [64]byte
|
|
|
|
buf1 []byte
|
|
|
|
buf2 []byte
|
|
|
|
str1 string
|
|
|
|
str2 string
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Buffer) foo() { // ERROR "\(\*Buffer\).foo b does not escape$"
|
|
|
|
b.buf1 = b.buf1[1:2] // ERROR "\(\*Buffer\).foo ignoring self-assignment to b.buf1$"
|
|
|
|
b.buf1 = b.buf1[1:2:3] // ERROR "\(\*Buffer\).foo ignoring self-assignment to b.buf1$"
|
|
|
|
b.buf1 = b.buf2[1:2] // ERROR "\(\*Buffer\).foo ignoring self-assignment to b.buf1$"
|
|
|
|
b.buf1 = b.buf2[1:2:3] // ERROR "\(\*Buffer\).foo ignoring self-assignment to b.buf1$"
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Buffer) bar() { // ERROR "leaking param: b$"
|
|
|
|
b.buf1 = b.arr[1:2] // ERROR "b.arr escapes to heap$"
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Buffer) baz() { // ERROR "\(\*Buffer\).baz b does not escape$"
|
|
|
|
b.str1 = b.str1[1:2] // ERROR "\(\*Buffer\).baz ignoring self-assignment to b.str1$"
|
|
|
|
b.str1 = b.str2[1:2] // ERROR "\(\*Buffer\).baz ignoring self-assignment to b.str1$"
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Buffer) bat() { // ERROR "leaking param content: b$"
|
2015-02-19 12:00:11 -07:00
|
|
|
o := new(Buffer) // ERROR "new\(Buffer\) escapes to heap$"
|
2015-01-16 13:30:35 -07:00
|
|
|
o.buf1 = b.buf1[1:2]
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = o // ERROR "o escapes to heap$"
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func quux(sp *string, bp *[]byte) { // ERROR "quux bp does not escape$" "quux sp does not escape$"
|
|
|
|
*sp = (*sp)[1:2] // ERROR "quux ignoring self-assignment to \*sp$"
|
|
|
|
*bp = (*bp)[1:2] // ERROR "quux ignoring self-assignment to \*bp$"
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
2015-01-21 07:37:59 -07:00
|
|
|
|
|
|
|
type StructWithString struct {
|
|
|
|
p *int
|
|
|
|
s string
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is escape analysis false negative.
|
|
|
|
// We assign the pointer to x.p but leak x.s. Escape analysis coarsens flows
|
|
|
|
// to just x, and thus &i looks escaping.
|
|
|
|
func fieldFlowTracking() {
|
|
|
|
var x StructWithString
|
2015-02-19 12:00:11 -07:00
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
x.p = &i // ERROR "&i escapes to heap$"
|
|
|
|
sink = x.s // ERROR "x.s escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// String operations.
|
|
|
|
|
|
|
|
func slicebytetostring0() {
|
2015-02-19 12:00:11 -07:00
|
|
|
b := make([]byte, 20) // ERROR "slicebytetostring0 make\(\[\]byte, 20\) does not escape$"
|
|
|
|
s := string(b) // ERROR "slicebytetostring0 string\(b\) does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func slicebytetostring1() {
|
2015-02-19 12:00:11 -07:00
|
|
|
b := make([]byte, 20) // ERROR "slicebytetostring1 make\(\[\]byte, 20\) does not escape$"
|
|
|
|
s := string(b) // ERROR "slicebytetostring1 string\(b\) does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
s1 := s[0:1]
|
|
|
|
_ = s1
|
|
|
|
}
|
|
|
|
|
|
|
|
func slicebytetostring2() {
|
2015-02-19 12:00:11 -07:00
|
|
|
b := make([]byte, 20) // ERROR "slicebytetostring2 make\(\[\]byte, 20\) does not escape$"
|
|
|
|
s := string(b) // ERROR "string\(b\) escapes to heap$"
|
|
|
|
s1 := s[0:1] // ERROR "moved to heap: s1$"
|
|
|
|
sink = &s1 // ERROR "&s1 escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func slicebytetostring3() {
|
2015-02-19 12:00:11 -07:00
|
|
|
b := make([]byte, 20) // ERROR "slicebytetostring3 make\(\[\]byte, 20\) does not escape$"
|
|
|
|
s := string(b) // ERROR "string\(b\) escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
s1 := s[0:1]
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = s1 // ERROR "s1 escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func addstr0() {
|
|
|
|
s0 := "a"
|
|
|
|
s1 := "b"
|
2015-02-19 12:00:11 -07:00
|
|
|
s := s0 + s1 // ERROR "addstr0 s0 \+ s1 does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func addstr1() {
|
|
|
|
s0 := "a"
|
|
|
|
s1 := "b"
|
|
|
|
s := "c"
|
2015-02-19 12:00:11 -07:00
|
|
|
s += s0 + s1 // ERROR "addstr1 s0 \+ s1 does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func addstr2() {
|
2015-02-19 12:00:11 -07:00
|
|
|
b := make([]byte, 20) // ERROR "addstr2 make\(\[\]byte, 20\) does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
s0 := "a"
|
2015-02-19 12:00:11 -07:00
|
|
|
s := string(b) + s0 // ERROR "addstr2 string\(b\) \+ s0 does not escape$" "addstr2 string\(b\) does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func addstr3() {
|
|
|
|
s0 := "a"
|
|
|
|
s1 := "b"
|
2015-02-19 12:00:11 -07:00
|
|
|
s := s0 + s1 // ERROR "s0 \+ s1 escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
s2 := s[0:1]
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = s2 // ERROR "s2 escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
}
|
2015-01-27 22:42:20 -07:00
|
|
|
|
|
|
|
func intstring0() bool {
|
|
|
|
// string does not escape
|
|
|
|
x := '0'
|
2015-02-19 12:00:11 -07:00
|
|
|
s := string(x) // ERROR "intstring0 string\(x\) does not escape$"
|
2015-01-27 22:42:20 -07:00
|
|
|
return s == "0"
|
|
|
|
}
|
|
|
|
|
|
|
|
func intstring1() string {
|
|
|
|
// string does not escape, but the buffer does
|
|
|
|
x := '0'
|
2015-02-19 12:00:11 -07:00
|
|
|
s := string(x) // ERROR "string\(x\) escapes to heap$"
|
2015-01-27 22:42:20 -07:00
|
|
|
return s
|
|
|
|
}
|
|
|
|
|
|
|
|
func intstring2() {
|
|
|
|
// string escapes to heap
|
|
|
|
x := '0'
|
2015-02-19 12:00:11 -07:00
|
|
|
s := string(x) // ERROR "moved to heap: s$" "string\(x\) escapes to heap$"
|
|
|
|
sink = &s // ERROR "&s escapes to heap$"
|
2015-01-27 22:42:20 -07:00
|
|
|
}
|
2015-01-29 23:14:13 -07:00
|
|
|
|
|
|
|
func stringtoslicebyte0() {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
x := []byte(s) // ERROR "stringtoslicebyte0 \(\[\]byte\)\(s\) does not escape$"
|
2015-01-29 23:14:13 -07:00
|
|
|
_ = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicebyte1() []byte {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
return []byte(s) // ERROR "\(\[\]byte\)\(s\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicebyte2() {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = []byte(s) // ERROR "\(\[\]byte\)\(s\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicerune0() {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
x := []rune(s) // ERROR "stringtoslicerune0 \(\[\]rune\)\(s\) does not escape$"
|
2015-01-29 23:14:13 -07:00
|
|
|
_ = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicerune1() []rune {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
return []rune(s) // ERROR "\(\[\]rune\)\(s\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicerune2() {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = []rune(s) // ERROR "\(\[\]rune\)\(s\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func slicerunetostring0() {
|
2015-02-19 12:00:11 -07:00
|
|
|
r := []rune{1, 2, 3} // ERROR "slicerunetostring0 \[\]rune literal does not escape$"
|
|
|
|
s := string(r) // ERROR "slicerunetostring0 string\(r\) does not escape$"
|
2015-01-29 23:14:13 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func slicerunetostring1() string {
|
2015-02-19 12:00:11 -07:00
|
|
|
r := []rune{1, 2, 3} // ERROR "slicerunetostring1 \[\]rune literal does not escape$"
|
|
|
|
return string(r) // ERROR "string\(r\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func slicerunetostring2() {
|
2015-02-19 12:00:11 -07:00
|
|
|
r := []rune{1, 2, 3} // ERROR "slicerunetostring2 \[\]rune literal does not escape$"
|
|
|
|
sink = string(r) // ERROR "string\(r\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
2015-01-29 09:40:02 -07:00
|
|
|
|
|
|
|
func makemap0() {
|
2015-02-19 12:00:11 -07:00
|
|
|
m := make(map[int]int) // ERROR "makemap0 make\(map\[int\]int\) does not escape$"
|
2015-01-29 09:40:02 -07:00
|
|
|
m[0] = 0
|
|
|
|
m[1]++
|
|
|
|
delete(m, 1)
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = m[0] // ERROR "m\[0\] escapes to heap$"
|
2015-01-29 09:40:02 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func makemap1() map[int]int {
|
2015-02-19 12:00:11 -07:00
|
|
|
return make(map[int]int) // ERROR "make\(map\[int\]int\) escapes to heap$"
|
2015-01-29 09:40:02 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func makemap2() {
|
2015-02-19 12:00:11 -07:00
|
|
|
m := make(map[int]int) // ERROR "make\(map\[int\]int\) escapes to heap$"
|
|
|
|
sink = m // ERROR "m escapes to heap$"
|
2015-02-19 06:27:32 -07:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func nonescapingEface(m map[interface{}]bool) bool { // ERROR "nonescapingEface m does not escape$"
|
|
|
|
return m["foo"] // ERROR "nonescapingEface .foo. does not escape$"
|
2015-02-19 06:27:32 -07:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func nonescapingIface(m map[M]bool) bool { // ERROR "nonescapingIface m does not escape$"
|
|
|
|
return m[MV(0)] // ERROR "nonescapingIface MV\(0\) does not escape$"
|
2015-01-29 09:40:02 -07:00
|
|
|
}
|
2015-04-06 09:17:20 -06:00
|
|
|
|
|
|
|
func issue10353() {
|
2015-02-19 12:00:11 -07:00
|
|
|
x := new(int) // ERROR "new\(int\) escapes to heap$"
|
2015-04-06 09:17:20 -06:00
|
|
|
issue10353a(x)()
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func issue10353a(x *int) func() { // ERROR "leaking param: x to result ~r1 level=-1$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return func() { // ERROR "func literal escapes to heap$"
|
2015-04-06 09:17:20 -06:00
|
|
|
println(*x)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func issue10353b() {
|
|
|
|
var f func()
|
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
x := new(int) // ERROR "new\(int\) escapes to heap$"
|
|
|
|
f = func() { // ERROR "func literal escapes to heap$"
|
2015-04-06 09:17:20 -06:00
|
|
|
println(*x)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_ = f
|
|
|
|
}
|
2015-06-24 15:31:57 -06:00
|
|
|
|
|
|
|
func issue11387(x int) func() int {
|
|
|
|
f := func() int { return x } // ERROR "func literal escapes to heap"
|
|
|
|
slice1 := []func() int{f} // ERROR "\[\].* does not escape"
|
|
|
|
slice2 := make([]func() int, 1) // ERROR "make\(.*\) does not escape"
|
|
|
|
copy(slice2, slice1)
|
|
|
|
return slice2[0]
|
|
|
|
}
|