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

Comments

Projects
None yet
10 participants
@bradfitz
Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

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

@mrjrieke

This comment has been minimized.

Copy link

commented Dec 16, 2016

Interesting...

@bcmills

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

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

@agnivade

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

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
@mdempsky

This comment has been minimized.

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.