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.
>
> On Wed, Oct 5, 2016 at 4:46 PM, 刘桂祥  
> 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
>>>  }(, 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, 刘桂祥  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  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, 刘桂祥  wrote:
>
>> // example1.go
>>
>> package main
>>
>>
>> func main() {
>>  var y int // BAD: y escapes
>>  func(p *int, x int) {
>>  *p = x
>>  }(, 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 := 
>>  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 .
>> 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.

Re: [go-nuts] go closure escape analysis

['Chris Manghane' via golang-nuts]

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: 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/g
>> olang/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
>>  }(, 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, 刘桂祥  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  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, 刘桂祥  wrote:

> // example1.go
>
> package main
>
>
> func main() {
>  var y int // BAD: y escapes
>  func(p *int, x int) {
>  *p = x
>  }(, 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 := 
>  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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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 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
>  }(, 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, 刘桂祥  
> 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  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, 刘桂祥  wrote:
>>>
 // example1.go

 package main


 func main() {
  var y int // BAD: y escapes
  func(p *int, x int) {
  *p = x
  }(, 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 := 
  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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go closure escape analysis

['Chris Manghane' via golang-nuts]

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
 }(, 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, 刘桂祥  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  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, 刘桂祥  wrote:
>>
>>> // example1.go
>>>
>>> package main
>>>
>>>
>>> func main() {
>>>  var y int // BAD: y escapes
>>>  func(p *int, x int) {
>>>  *p = x
>>>  }(, 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 := 
>>>  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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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 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, 刘桂祥  
> wrote:
>
>> // example1.go
>>
>> package main
>>
>>
>> func main() {
>>  var y int // BAD: y escapes
>>  func(p *int, x int) {
>>  *p = x
>>  }(, 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 := 
>>  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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go closure escape analysis

[thebrokentoaster]

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 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, 刘桂祥  
> wrote:
>
>> // example1.go
>>
>> package main
>>
>>
>> func main() {
>>  var y int // BAD: y escapes
>>  func(p *int, x int) {
>>  *p = x
>>  }(, 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 := 
>>  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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.