@dr2chase time for your explainer to shine!

That'd be great - there are some more cases in the linked package github.com/tschottdorf/goplay/alloc_tests.

Short answer is loop nesting depth -- assigning in-loop mem to outside-loop data results in escape
Will try explainer on it later.

That can't be it, this still allocs:

diff --git a/alloc_tests/alloc_test.go b/alloc_tests/alloc_test.go
index a8bc976..a8ccabb 100644
--- a/alloc_tests/alloc_test.go
+++ b/alloc_tests/alloc_test.go
@@ -27,10 +27,10 @@ func BenchmarkClosurePtrFromScope(b *testing.B) {
 }

 func BenchmarkClosurePtrFromArg(b *testing.B) {
-   inc := func(k *int) {
-       *k++
-   }
    for j := 0; j < b.N; j++ {
+       inc := func(k *int) {
+           *k++
+       }
        var i int // does escape
        inc(&i)
    }

Much simpler answer: indirect call. Escape analysis knows nothing about any constants that you might propagate, such as function bodies. That's something that would be nice to do in the future, but right now, it's thoroughly upstream of SSA (yes, I know this is annoying).

go test -run - -bench . -benchmem -gcflags '-m -m -l -e'
# _/Users/drchase/GoogleDrive/work/tmp/ESC
./esc_bench.go:11: moved to heap: i
./esc_bench.go:12: &i escapes to heap
./esc_bench.go:12:  from inc(&i) (parameter to indirect call) at ./esc_bench.go:12
./esc_bench.go:7: BenchmarkClosurePtrFromArg.func1 k does not escape
./esc_bench.go:6: BenchmarkClosurePtrFromArg b does not escape
./esc_bench.go:7: BenchmarkClosurePtrFromArg func literal does not escape

But, what do you think of the explainer?

Not sure I follow. Maybe an explanation why BenchmarkClosurePtrFromScope does not alloc would illustrate this nicely - I naively would've expected that to be exactly equivalent in SSA.

👍 on the explainer (ran across it on multiple occasions). It'd be interesting to be able to use the output for code highlighting - the only missing part is giving not online line numbers, but also a char range in that line if that's possible. (something like 12:56-89 for line 12 chars 56-89).

Having the explainer explain negatives is a bit more work. In this case, &i is not a parameter to an indirect call, so it is okay. SSA is very much (right now) a back-end-only phase, run well after escape analysis decisions have been made. Indirect calls are treated like they are radioactive, but we can still see that the closure itself doesn't escape, nor does it assign to globals.

@dr2chase Thanks. I'm still not really following what's going on, but I think I can just look at your explainer (which presumably would give me some ideas about what the corresponding SSA for the above example looks like). Do you have its source online somewhere?

Also, no point in keeping this issue open, correct?

The explainer is now in pre-1.7. Build with -gcflags '-m -m' and you'll get explanations. The code for the explainer is interspersed through esc.go, which runs upstream of SSA.

And there's no point keeping this open now, you are correct.

Excellent, thanks again.

On Wed, Mar 30, 2016 at 11:11 PM dr2chase notifications@github.com wrote:

The explainer is now in pre-1.7. Build with -gcflags '-m -m' and you'll
get explanations. The code for the explainer is interspersed through
esc.go, which runs upstream of SSA.

And there's no point keeping this open now, you are correct.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#14699 (comment)