Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: investigate closure capture issue #18300

Open
bradfitz opened this issue Dec 13, 2016 · 7 comments
Open

cmd/compile: investigate closure capture issue #18300

bradfitz opened this issue Dec 13, 2016 · 7 comments

Comments

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 13, 2016

This change reduces allocations:

https://go-review.googlesource.com/c/33765/4/src/encoding/json/encode.go

Why? Can the compiler be changed instead?

(See test file in same CL for details)

/cc @randall77 @mdempsky @aclements

@bradfitz bradfitz added this to the Go1.9Maybe milestone Dec 13, 2016
@randall77
Copy link
Contributor

@randall77 randall77 commented Dec 13, 2016

I suspect this would require a finer-grained escape analysis. Contrast these:

  f := new(int)
  doesntEscape(f)
  f = new(int)
  escapes(f)
  x := new(int)
  doesntEscape(x)
  y := new(int)
  escapes(y)

There's only one declaration in the first example. Escape analysis works on declarations. So f has to be declared as escaping. In contrast, the second example has 2 declarations so x can be seen to not escape.

I guess escape analysis would have to be augmented to split declarations into unconnected subsets somehow and then treat each subset independently.

@dr2chase

Loading

@mrjrieke
Copy link

@mrjrieke mrjrieke commented Dec 16, 2016

Interesting...

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Apr 28, 2017

Escape analysis works on declarations.

Does that change with SSA? I would expect escape analysis to apply to SSA variables/slots/whatever rather than source variables.

Loading

@dr2chase
Copy link
Contributor

@dr2chase dr2chase commented May 2, 2017

No change here, sorry.

Loading

@bradfitz bradfitz removed this from the Go1.9Maybe milestone Jul 20, 2017
@bradfitz bradfitz added this to the Go1.10 milestone Jul 20, 2017
@bradfitz bradfitz added this to the Go1.10 milestone Jul 20, 2017
@bradfitz bradfitz removed this from the Go1.9Maybe milestone Jul 20, 2017
@cherrymui cherrymui removed this from the Go1.10 milestone Nov 29, 2017
@cherrymui cherrymui added this to the Go1.11 milestone Nov 29, 2017
@gopherbot gopherbot removed this from the Go1.11 milestone May 23, 2018
@gopherbot gopherbot added this to the Unplanned milestone May 23, 2018
@agnivade
Copy link
Contributor

@agnivade agnivade commented Mar 23, 2019

@randall77 - Your example does not escape now.

package main

func main() {
	f := new(int)
	f1(f)
	f = new(int)
	f2(f)
}

//go:noinline
func f1(i *int) {
	_ = i
}

//go:noinline
func f2(i *int) {
	_ = i
}
$gotip build -gcflags='-m' funnel_logger.go
# command-line-arguments
./funnel_logger.go:11:9: f1 i does not escape
./funnel_logger.go:16:9: f2 i does not escape
./funnel_logger.go:4:10: main new(int) does not escape
./funnel_logger.go:6:9: main new(int) does not escape

Has anything changed ?

gotip version
go version devel +e96c4ace9c Mon Mar 18 10:50:57 2019 +0530 linux/amd64

Loading

@randall77
Copy link
Contributor

@randall77 randall77 commented Mar 23, 2019

No, this still doesn't work. You need to declare f2 like:

//go:noinline
func f2(i *int) {
	sink = i
}

var sink *int

Then you get

/Users/khr/gowork/issue18300.go:11:9: f1 i does not escape
/Users/khr/gowork/issue18300.go:16:9: leaking param: i
/Users/khr/gowork/issue18300.go:4:10: new(int) escapes to heap
/Users/khr/gowork/issue18300.go:6:9: new(int) escapes to heap

Loading

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Apr 16, 2019

Still an issue with newescape. Should be fixed by porting escape analysis to SSA (#31501); maybe fixable separately, but probably not worth the complexity.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants