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
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone

Comments

@bradfitz
Copy link
Contributor

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

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

@mrjrieke
Copy link

Interesting...

@bcmills
Copy link
Member

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.

@dr2chase
Copy link
Contributor

dr2chase commented May 2, 2017

No change here, sorry.

@bradfitz bradfitz modified the milestones: Go1.9Maybe, Go1.10 Jul 20, 2017
@cherrymui cherrymui modified the milestones: Go1.10, Go1.11 Nov 29, 2017
@gopherbot gopherbot modified the milestones: Go1.11, Unplanned May 23, 2018
@ALTree ALTree added Performance NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 22, 2018
@agnivade
Copy link
Contributor

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

@randall77
Copy link
Contributor

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

@mdempsky
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
None yet
Development

No branches or pull requests

10 participants