Re: [go-nuts] go closure escape analysis

ok very thanks! 在 2016年10月6日星期四 UTC+8上午7:49:03，Chris Manghane写道： > > To see the escape analysis results, compile with -gcflags "-m -m -m -m". > The code in each of the example should be relatively similar, which is why > it is a bug that one of them causes the variable to escape to the heap.

Re: [go-nuts] go closure escape analysis

To see the escape analysis results, compile with -gcflags "-m -m -m -m". The code in each of the example should be relatively similar, which is why it is a bug that one of them causes the variable to escape to the heap. On Wed, Oct 5, 2016 at 4:46 PM, 刘桂祥 wrote: > 1:

Re: [go-nuts] go closure escape analysis

1: In example2_modified.go (y=x line should be *y=x ?) and that is the same as example1.go ??? but in example1.go y is escapted and example2.go is not. 2:how do I see the compile handle closure call results ? compile para ? 在 2016年10月5日星期三 UTC+8下午11:38:42，Chris Manghane写道： > > Sorry, poor

Re: [go-nuts] go closure escape analysis

Sorry, poor explanation again. When a variable is used from outside a closure's scope, it is *captured* by the closure. Usually that means that the closure function is modified to include a reference to that variable when it is called as a regular function. An example from the compiler:

Re: [go-nuts] go closure escape analysis

In go when closure call the out varible will pass pointer to the closure func so I doubt in example2.go y is passed to closure I don't know the compile how to analysis this and decide that can be allocated in stack correctly ? 在 2016年10月4日星期二 UTC+8下午11:54:02，Chris Manghane写道： > > In

Re: [go-nuts] go closure escape analysis

Example 1 is a known issue: https://github.com/golang/go/issues/7714 In fact your example is identical to the one Keith presented. On Tuesday, October 4, 2016 at 8:54:02 AM UTC-7, Chris Manghane wrote: > > In example1, the // BAD: y escapes is there because y should not escape > from that