2015-02-19 19:10:31 +03:00
|
|
|
// errorcheck -0 -m -l
|
|
|
|
|
2016-04-11 00:32:26 +03:00
|
|
|
// Copyright 2015 The Go Authors. All rights reserved.
|
2015-02-19 19:10:31 +03:00
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
// Test escape analysis for function parameters.
|
|
|
|
|
|
|
|
// In this test almost everything is BAD except the simplest cases
|
|
|
|
// where input directly flows to output.
|
|
|
|
|
|
|
|
package escape
|
|
|
|
|
|
|
|
var sink interface{}
|
|
|
|
|
|
|
|
// in -> out
|
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 23:36:15 +03:00
|
|
|
func param0(p *int) *int { // ERROR "leaking param: p to result ~r1"
|
2015-02-19 19:10:31 +03:00
|
|
|
return p
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller0a() {
|
|
|
|
i := 0
|
|
|
|
_ = param0(&i) // ERROR "caller0a &i does not escape$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller0b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
sink = param0(&i) // ERROR "&i escapes to heap$" "param0\(&i\) escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
// in, in -> out, out
|
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 23:36:15 +03:00
|
|
|
func param1(p1, p2 *int) (*int, *int) { // ERROR "leaking param: p1 to result ~r2" "leaking param: p2 to result ~r3"
|
2015-02-19 19:10:31 +03:00
|
|
|
return p1, p2
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller1() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
j := 0
|
|
|
|
sink, _ = param1(&i, &j) // ERROR "&i escapes to heap$" "caller1 &j does not escape$"
|
|
|
|
}
|
|
|
|
|
|
|
|
// in -> other in
|
|
|
|
func param2(p1 *int, p2 **int) { // ERROR "leaking param: p1$" "param2 p2 does not escape$"
|
|
|
|
*p2 = p1
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller2a() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int
|
|
|
|
param2(&i, &p) // ERROR "&i escapes to heap$" "caller2a &p does not escape$"
|
|
|
|
_ = p
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller2b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int
|
|
|
|
param2(&i, &p) // ERROR "&i escapes to heap$" "caller2b &p does not escape$"
|
|
|
|
sink = p // ERROR "p escapes to heap$"
|
|
|
|
}
|
|
|
|
|
2018-07-27 19:32:17 +03:00
|
|
|
func paramArraySelfAssign(p *PairOfPairs) { // ERROR "p does not escape"
|
|
|
|
p.pairs[0] = p.pairs[1] // ERROR "ignoring self-assignment in p.pairs\[0\] = p.pairs\[1\]"
|
|
|
|
}
|
|
|
|
|
|
|
|
type PairOfPairs struct {
|
|
|
|
pairs [2]*Pair
|
|
|
|
}
|
|
|
|
|
|
|
|
type BoxedPair struct {
|
|
|
|
pair *Pair
|
|
|
|
}
|
|
|
|
|
|
|
|
type WrappedPair struct {
|
|
|
|
pair Pair
|
|
|
|
}
|
|
|
|
|
|
|
|
func leakParam(x interface{}) { // ERROR "leaking param: x"
|
|
|
|
sink = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func sinkAfterSelfAssignment1(box *BoxedPair) { // ERROR "leaking param content: box"
|
|
|
|
box.pair.p1 = box.pair.p2 // ERROR "ignoring self-assignment in box.pair.p1 = box.pair.p2"
|
|
|
|
sink = box.pair.p2 // ERROR "box.pair.p2 escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func sinkAfterSelfAssignment2(box *BoxedPair) { // ERROR "leaking param content: box"
|
|
|
|
box.pair.p1 = box.pair.p2 // ERROR "ignoring self-assignment in box.pair.p1 = box.pair.p2"
|
|
|
|
sink = box.pair // ERROR "box.pair escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func sinkAfterSelfAssignment3(box *BoxedPair) { // ERROR "leaking param content: box"
|
|
|
|
box.pair.p1 = box.pair.p2 // ERROR "ignoring self-assignment in box.pair.p1 = box.pair.p2"
|
|
|
|
leakParam(box.pair.p2) // ERROR "box.pair.p2 escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func sinkAfterSelfAssignment4(box *BoxedPair) { // ERROR "leaking param content: box"
|
|
|
|
box.pair.p1 = box.pair.p2 // ERROR "ignoring self-assignment in box.pair.p1 = box.pair.p2"
|
|
|
|
leakParam(box.pair) // ERROR "box.pair escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func selfAssignmentAndUnrelated(box1, box2 *BoxedPair) { // ERROR "leaking param content: box2" "box1 does not escape"
|
|
|
|
box1.pair.p1 = box1.pair.p2 // ERROR "ignoring self-assignment in box1.pair.p1 = box1.pair.p2"
|
|
|
|
leakParam(box2.pair.p2) // ERROR "box2.pair.p2 escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func notSelfAssignment1(box1, box2 *BoxedPair) { // ERROR "leaking param content: box2" "box1 does not escape"
|
|
|
|
box1.pair.p1 = box2.pair.p1
|
|
|
|
}
|
|
|
|
|
|
|
|
func notSelfAssignment2(p1, p2 *PairOfPairs) { // ERROR "leaking param content: p2" "p1 does not escape"
|
|
|
|
p1.pairs[0] = p2.pairs[1]
|
|
|
|
}
|
|
|
|
|
|
|
|
func notSelfAssignment3(p1, p2 *PairOfPairs) { // ERROR "leaking param content: p2" "p1 does not escape"
|
|
|
|
p1.pairs[0].p1 = p2.pairs[1].p1
|
|
|
|
}
|
|
|
|
|
|
|
|
func boxedPairSelfAssign(box *BoxedPair) { // ERROR "box does not escape"
|
|
|
|
box.pair.p1 = box.pair.p2 // ERROR "ignoring self-assignment in box.pair.p1 = box.pair.p2"
|
|
|
|
}
|
|
|
|
|
|
|
|
func wrappedPairSelfAssign(w *WrappedPair) { // ERROR "w does not escape"
|
|
|
|
w.pair.p1 = w.pair.p2 // ERROR "ignoring self-assignment in w.pair.p1 = w.pair.p2"
|
|
|
|
}
|
|
|
|
|
2015-02-19 19:10:31 +03:00
|
|
|
// in -> in
|
|
|
|
type Pair struct {
|
|
|
|
p1 *int
|
|
|
|
p2 *int
|
|
|
|
}
|
|
|
|
|
2018-07-27 19:32:17 +03:00
|
|
|
func param3(p *Pair) { // ERROR "param3 p does not escape"
|
|
|
|
p.p1 = p.p2 // ERROR "param3 ignoring self-assignment in p.p1 = p.p2"
|
2015-02-19 19:10:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
func caller3a() {
|
2018-07-27 19:32:17 +03:00
|
|
|
i := 0
|
|
|
|
j := 0
|
|
|
|
p := Pair{&i, &j} // ERROR "caller3a &i does not escape" "caller3a &j does not escape"
|
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 23:36:15 +03:00
|
|
|
param3(&p) // ERROR "caller3a &p does not escape"
|
2015-02-19 19:10:31 +03:00
|
|
|
_ = p
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller3b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
j := 0 // ERROR "moved to heap: j$"
|
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 23:36:15 +03:00
|
|
|
p := Pair{&i, &j} // ERROR "&i escapes to heap$" "&j escapes to heap$"
|
|
|
|
param3(&p) // ERROR "caller3b &p does not escape"
|
2015-02-19 19:10:31 +03:00
|
|
|
sink = p // ERROR "p escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
// in -> rcvr
|
|
|
|
func (p *Pair) param4(i *int) { // ERROR "\(\*Pair\).param4 p does not escape$" "leaking param: i$"
|
|
|
|
p.p1 = i
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller4a() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := Pair{}
|
|
|
|
p.param4(&i) // ERROR "&i escapes to heap$" "caller4a p does not escape$"
|
|
|
|
_ = p
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller4b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := Pair{}
|
|
|
|
p.param4(&i) // ERROR "&i escapes to heap$" "caller4b p does not escape$"
|
|
|
|
sink = p // ERROR "p escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
// in -> heap
|
|
|
|
func param5(i *int) { // ERROR "leaking param: i$"
|
|
|
|
sink = i // ERROR "i escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller5() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
param5(&i) // ERROR "&i escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
// *in -> heap
|
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 23:36:15 +03:00
|
|
|
func param6(i ***int) { // ERROR "leaking param content: i$"
|
2015-02-19 19:10:31 +03:00
|
|
|
sink = *i // ERROR "\*i escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller6a() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$" "moved to heap: p$"
|
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 23:36:15 +03:00
|
|
|
p2 := &p // ERROR "&p escapes to heap$"
|
|
|
|
param6(&p2) // ERROR "caller6a &p2 does not escape"
|
2015-02-19 19:10:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// **in -> heap
|
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 23:36:15 +03:00
|
|
|
func param7(i ***int) { // ERROR "leaking param content: i$"
|
2015-02-19 19:10:31 +03:00
|
|
|
sink = **i // ERROR "\* \(\*i\) escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller7() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$" "moved to heap: p$"
|
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 23:36:15 +03:00
|
|
|
p2 := &p // ERROR "&p escapes to heap$"
|
|
|
|
param7(&p2) // ERROR "caller7 &p2 does not escape"
|
2015-02-19 19:10:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// **in -> heap
|
|
|
|
func param8(i **int) { // ERROR "param8 i does not escape$"
|
|
|
|
sink = **i // ERROR "\* \(\*i\) escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller8() {
|
|
|
|
i := 0
|
|
|
|
p := &i // ERROR "caller8 &i does not escape$"
|
|
|
|
param8(&p) // ERROR "caller8 &p does not escape$"
|
|
|
|
}
|
|
|
|
|
|
|
|
// *in -> out
|
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 23:36:15 +03:00
|
|
|
func param9(p ***int) **int { // ERROR "leaking param: p to result ~r1 level=1"
|
2015-02-19 19:10:31 +03:00
|
|
|
return *p
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller9a() {
|
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 23:36:15 +03:00
|
|
|
i := 0
|
|
|
|
p := &i // ERROR "caller9a &i does not escape"
|
|
|
|
p2 := &p // ERROR "caller9a &p does not escape"
|
2015-02-19 19:10:31 +03:00
|
|
|
_ = param9(&p2) // ERROR "caller9a &p2 does not escape$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller9b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$" "moved to heap: p$"
|
|
|
|
p2 := &p // ERROR "&p escapes to heap$"
|
|
|
|
sink = param9(&p2) // ERROR "caller9b &p2 does not escape$" "param9\(&p2\) escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
// **in -> out
|
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 23:36:15 +03:00
|
|
|
func param10(p ***int) *int { // ERROR "leaking param: p to result ~r1 level=2"
|
2015-02-19 19:10:31 +03:00
|
|
|
return **p
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller10a() {
|
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 23:36:15 +03:00
|
|
|
i := 0
|
|
|
|
p := &i // ERROR "caller10a &i does not escape"
|
|
|
|
p2 := &p // ERROR "caller10a &p does not escape"
|
2015-02-19 19:10:31 +03:00
|
|
|
_ = param10(&p2) // ERROR "caller10a &p2 does not escape$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller10b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
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 23:36:15 +03:00
|
|
|
p := &i // ERROR "&i escapes to heap$"
|
|
|
|
p2 := &p // ERROR "caller10b &p does not escape$"
|
2015-02-19 19:10:31 +03:00
|
|
|
sink = param10(&p2) // ERROR "caller10b &p2 does not escape$" "param10\(&p2\) escapes to heap"
|
|
|
|
}
|
|
|
|
|
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 23:36:15 +03:00
|
|
|
// in escapes to heap (address of param taken and returned)
|
2015-02-19 19:10:31 +03:00
|
|
|
func param11(i **int) ***int { // ERROR "moved to heap: i$"
|
|
|
|
return &i // ERROR "&i escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller11a() {
|
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 23:36:15 +03:00
|
|
|
i := 0 // ERROR "moved to heap: i"
|
|
|
|
p := &i // ERROR "moved to heap: p" "&i escapes to heap"
|
|
|
|
_ = param11(&p) // ERROR "&p escapes to heap"
|
2015-02-19 19:10:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
func caller11b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$" "moved to heap: p$"
|
|
|
|
sink = param11(&p) // ERROR "&p escapes to heap$" "param11\(&p\) escapes to heap"
|
|
|
|
}
|
|
|
|
|
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 23:36:15 +03:00
|
|
|
func caller11c() { // GOOD
|
2015-02-19 19:10:31 +03:00
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
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 23:36:15 +03:00
|
|
|
p := &i // ERROR "moved to heap: p" "&i escapes to heap"
|
|
|
|
sink = *param11(&p) // ERROR "&p escapes to heap" "\*param11\(&p\) escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller11d() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap" "moved to heap: p"
|
|
|
|
p2 := &p // ERROR "&p escapes to heap"
|
|
|
|
sink = param11(p2) // ERROR "param11\(p2\) escapes to heap"
|
2015-02-19 19:10:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// &in -> rcvr
|
|
|
|
type Indir struct {
|
|
|
|
p ***int
|
|
|
|
}
|
|
|
|
|
|
|
|
func (r *Indir) param12(i **int) { // ERROR "\(\*Indir\).param12 r does not escape$" "moved to heap: i$"
|
|
|
|
r.p = &i // ERROR "&i escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller12a() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$" "moved to heap: p$"
|
|
|
|
var r Indir
|
|
|
|
r.param12(&p) // ERROR "&p escapes to heap$" "caller12a r does not escape$"
|
|
|
|
_ = r
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller12b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$" "moved to heap: p$"
|
|
|
|
r := &Indir{} // ERROR "caller12b &Indir literal does not escape$"
|
|
|
|
r.param12(&p) // ERROR "&p escapes to heap$"
|
|
|
|
_ = r
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller12c() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$" "moved to heap: p$"
|
|
|
|
r := Indir{}
|
|
|
|
r.param12(&p) // ERROR "&p escapes to heap$" "caller12c r does not escape$"
|
|
|
|
sink = r // ERROR "r escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller12d() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
p := &i // ERROR "&i escapes to heap$" "moved to heap: p$"
|
|
|
|
r := Indir{}
|
|
|
|
r.param12(&p) // ERROR "&p escapes to heap$" "caller12d r does not escape$"
|
|
|
|
sink = **r.p // ERROR "\* \(\*r\.p\) escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
// in -> value rcvr
|
|
|
|
type Val struct {
|
|
|
|
p **int
|
|
|
|
}
|
|
|
|
|
|
|
|
func (v Val) param13(i *int) { // ERROR "Val.param13 v does not escape$" "leaking param: i$"
|
|
|
|
*v.p = i
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller13a() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int
|
|
|
|
var v Val
|
|
|
|
v.p = &p // ERROR "caller13a &p does not escape$"
|
|
|
|
v.param13(&i) // ERROR "&i escapes to heap$"
|
|
|
|
_ = v
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller13b() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int
|
|
|
|
v := Val{&p} // ERROR "caller13b &p does not escape$"
|
|
|
|
v.param13(&i) // ERROR "&i escapes to heap$"
|
|
|
|
_ = v
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller13c() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int
|
|
|
|
v := &Val{&p} // ERROR "caller13c &Val literal does not escape$" "caller13c &p does not escape$"
|
|
|
|
v.param13(&i) // ERROR "&i escapes to heap$"
|
|
|
|
_ = v
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller13d() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int // ERROR "moved to heap: p$"
|
|
|
|
var v Val
|
|
|
|
v.p = &p // ERROR "&p escapes to heap$"
|
|
|
|
v.param13(&i) // ERROR "&i escapes to heap$"
|
|
|
|
sink = v // ERROR "v escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller13e() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int // ERROR "moved to heap: p$"
|
|
|
|
v := Val{&p} // ERROR "&p escapes to heap$"
|
|
|
|
v.param13(&i) // ERROR "&i escapes to heap$"
|
|
|
|
sink = v // ERROR "v escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller13f() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int // ERROR "moved to heap: p$"
|
|
|
|
v := &Val{&p} // ERROR "&Val literal escapes to heap$" "&p escapes to heap$"
|
|
|
|
v.param13(&i) // ERROR "&i escapes to heap$"
|
|
|
|
sink = v // ERROR "v escapes to heap$"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller13g() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int
|
|
|
|
v := Val{&p} // ERROR "caller13g &p does not escape$"
|
|
|
|
v.param13(&i) // ERROR "&i escapes to heap$"
|
|
|
|
sink = *v.p // ERROR "\*v\.p escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func caller13h() {
|
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
|
|
|
var p *int
|
|
|
|
v := &Val{&p} // ERROR "caller13h &Val literal does not escape$" "caller13h &p does not escape$"
|
|
|
|
v.param13(&i) // ERROR "&i escapes to heap$"
|
|
|
|
sink = **v.p // ERROR "\* \(\*v\.p\) escapes to heap"
|
|
|
|
}
|
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 23:36:15 +03:00
|
|
|
|
|
|
|
type Node struct {
|
|
|
|
p *Node
|
|
|
|
}
|
|
|
|
|
|
|
|
var Sink *Node
|
|
|
|
|
|
|
|
func f(x *Node) { // ERROR "leaking param content: x"
|
|
|
|
Sink = &Node{x.p} // ERROR "&Node literal escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func g(x *Node) *Node { // ERROR "leaking param: x to result ~r1 level=0"
|
|
|
|
return &Node{x.p} // ERROR "&Node literal escapes to heap"
|
|
|
|
}
|
|
|
|
|
|
|
|
func h(x *Node) { // ERROR "leaking param: x"
|
|
|
|
y := &Node{x} // ERROR "h &Node literal does not escape"
|
|
|
|
Sink = g(y)
|
|
|
|
f(y)
|
|
|
|
}
|