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. > > On Wed, Oct 5, 2016 at 4:46 PM, 刘桂祥 <liuguix...@gmail.com <javascript:>> > wrote: > >> 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> 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. >>>> 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.
