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 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: > https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/closure.go#L311 > . > > In example2, this > > // example2.go > > package main > > func main() { > var y int > func(x int) { > y = x > }(42) > } > > is transformed into something like > > // example2_modified.go > > package main > > func main() { > var y int > func(y *int, x int) { > y = x > }(&y, 42) > } > > and then the same analysis from above is applied. y should not escape to > the heap here, similar to example3.go. > > Hope that clarifies, > Chris > > On Wed, Oct 5, 2016 at 6:18 AM, 刘桂祥 <liuguix...@gmail.com <javascript:>> > wrote: > >> In go when closure call the out varible will pass pointer to the >> closure func so I doubt in example2.go y is passed &y 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 example1, the // BAD: y escapes is there because y should not escape >>> from that function, but the current algorithm needs to be improved for this >>> case. In that closure, the address of y is captured as the closure argument >>> p and since p is only dereferenced, the analysis should not consider it to >>> escape. >>> >>> In example3, the analysis above applies and y should not escape. y is >>> closed over and dereferenced, but we correctly do not mark it as escaping. >>> >>> In example2, y contains no pointers; it can never escape. The test was >>> to see if capturing/closing over a non-pointer value would cause it to >>> escape. >>> >>> It's a bit confusing, but to restate, in example1, y should not escape >>> even though it currently does. >>> >>> On Mon, Oct 3, 2016 at 11:09 PM, 刘桂祥 <liuguix...@gmail.com> wrote: >>> >>>> // example1.go >>>> >>>> package main >>>> >>>> >>>> func main() { >>>> var y int // BAD: y escapes >>>> func(p *int, x int) { >>>> *p = x >>>> }(&y, 42) >>>> } >>>> >>>> example1.go y escape to the heap >>>> >>>> // example2.go >>>> >>>> package main >>>> >>>> func main() { >>>> var y int >>>> func(x int) { >>>> y = x >>>> }(42) >>>> } >>>> >>>> example2.go y is not escaped and why ?? >>>> >>>> // example3.go >>>> >>>> package main >>>> >>>> func main() { >>>> a := 100 >>>> y := &a >>>> func(x int) { >>>> *y = x >>>> }(42) >>>> } >>>> >>>> example3.go y is not escaped and why ?? >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golang-nuts...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
