Hi Paul,
Perhaps my answer was a bit simplistic, and I admit that I answered without
looking too much into it.
Basically, in your index1, the opts.isDigit passed to IndexFunc is
> syntactic sugar for ().isDigit -> then the compiler needs to move opts
> on the heap.
"*Why? Taking a reference to a function argument shouldn't automatically
move it to the heap. As long as the function doesn't store or return the
reference, it doesn't exist beyond the scope of that function. Escape
analysis should be able to figure that out and leave the value on the
stack. My real code passes to several functions without issue. The
only ones that cause a problem are the IndexFunc calls.*"
I agree with you re: the escape analysis ought to able to detect that
scenario - my initial reasoning here was that the compiler could be taking
the safest approach for the following scenario:
- the ().isDigit function is passed to IndexFunc (or any other
function).
- that IndexFunc function may or may not diverge into concurrent execution
(using go ... )
- while those detached execution flows are still running, the opts variable
runs the risk of being popped out of its stack existence when index1
returns, so ().isDigit would not be addressable from the other
execution threads.
That was my reasoning at the time I replied. But in the meanwhile, out of
curiosity, I took IndexFunc and its private sister function, indexFunc out
of the strings package, and added a convoluted go routine inside that
private indexFunc, that takes the function as a parameter, and sleeps for a
number of seconds. In the meanwhile the main execution flow returns. From
what I'm seeing, from that moment on, index2 -> opts also (correctly)
escapes to heap.
This leaves me with agreeing with you and Roger that there's room for
improvement.
For your index2 function question, I think it's because Go maintains the
> variables from a parent function that are referred in an enclosed function
> (closure) for as long as both are alive.
> I'm guessing that opts.IsDigit(r) is alive and kicking till it returns.
"*Sorry, I'm not sure what you mean by this. Could you expand on it?*"
What I meant is that the closure, that wrapper func you created inside
index2 is aware of the surrounding scope, and stateful. It will have access
to for as long as it's alive.
cheers
silviu
On Wed, Sep 5, 2018 at 8:15 AM wrote:
>
> FYI, here is the escape analysis output.
>
>
> $ go build -gcflags="-l -m=2"
>
> ./escape.go:20:10: capturing by ref: opts (addr=true assign=false
> width=4)
> ./escape.go:9:38: (*options).isDigit opts does not escape
> ./escape.go:15:34: opts escapes to heap
> ./escape.go:15:34: from opts.isDigit (call part) at ./escape.go:15:34
> ./escape.go:14:37: moved to heap: opts
> ./escape.go:14:37: index1 s does not escape
> ./escape.go:15:34: index1 opts.isDigit does not escape
> ./escape.go:18:37: index2 s does not escape
> ./escape.go:19:30: index2 func literal does not escape
> ./escape.go:20:14: index2.func1 opts does not escape
>
>
> Line 15 is the call to IndexFunc from the function index1. I think "call
> part" is supposed to be the reason that opts escapes to the heap but I
> couldn't find any information about what that means.
>
>
> On Wednesday, September 5, 2018 at 7:03:12 AM UTC-5, Paul D wrote:
>>
>> Hi Silviu,
>>
>> Thanks for your reply. I'm not sure about the points you raise though.
>>
>> Basically, in your index1, the opts.isDigit passed to IndexFunc is
>>> syntactic sugar for ().isDigit -> then the compiler needs to move opts
>>> on the heap.
>>
>>
>> Why? Taking a reference to a function argument shouldn't automatically
>> move it to the heap. As long as the function doesn't store or return the
>> reference, it doesn't exist beyond the scope of that function. Escape
>> analysis should be able to figure that out and leave the value on the
>> stack. My real code passes to several functions without issue. The
>> only ones that cause a problem are the IndexFunc calls.
>>
>> For your index2 function question, I think it's because Go maintains the
>>> variables from a parent function that are referred in an enclosed function
>>> (closure) for as long as both are alive.
>>> I'm guessing that opts.IsDigit(r) is alive and kicking till it returns.
>>
>>
>> Sorry, I'm not sure what you mean by this. Could you expand on it?
>>
>> Thanks,
>> Paul
>>
>>
>> On Tuesday, September 4, 2018 at 11:05:39 PM UTC-5, Silviu Capota Mera
>> wrote:
>>>
>>> Hi Paul,
>>>
>>> Check out: https://golang.org/doc/effective_go.html#pointers_vs_values
>>>
>>> Basically, in your in
