That's not generally how it works, FWIW. Especially as far as escape
analysis is concerned, the default is to escape and the compiler only marks
it as non-escaping if it can prove so. So, the heuristic might not be
perfect, but the only "unreasonable" imperfection would be, if it would put
things on the stack which don't belong there. Any "the heuristic is not
good enough to prove that it doesn't have to go on the heap" is, absent
evidence of the opposite, a reasonable imperfection.
That being said, maybe someone can give a good reason as to why large
values shouldn't always live on the stack. To me, that seems pretty natural
- we generally want the stack to be relatively small (because we might need
to have a lot of them) and we don't want it to grow in large steps (because
then we might have to repeatedly grow/shrink them, when a function is
called in a loop). And to me, slices and arrays seem naturally different -
one is just a chunk of memory, the other is such a chunk of memory and a
header containing a pointer to it. I agree that it's *probably* possible to
either also have large arrays escape or also have large slices live on the
stack - depending on what's more efficient. But I'm not enough of an expert
to answer that.
As I said, maybe someone else can. Or maybe you should just try and collect
data and file an issue, if you want this to change.
On Sun, May 23, 2021 at 12:57 PM tapi...@gmail.com <tapir....@gmail.com>
wrote:
> I do agree escape analysis is hard and gc is clever enough to handle many
> cases.
> But at this specified case, I think it is really unreasonable, unless
> someone could provide a reasonable explanation.
>
> On Sunday, May 23, 2021 at 6:16:04 AM UTC-4 axel.wa...@googlemail.com
> wrote:
>
>> I think you should be careful using terms like "not reasonable".
>>
>> If you don't believe the existing heuristic to be good, my recommendation
>> would be to collect some data on that, showing that for a useful corpus of
>> Go programs, the heuristics lead to more adverse effects (e.g. slower
>> programs) than an alternative you would suggest. But it's not productive to
>> just black-box poke at escape analysis using toy examples and derive broad
>> judgments about the existing heuristics from that.
>>
>> On Sun, May 23, 2021 at 11:57 AM tapi...@gmail.com <tapi...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sunday, May 23, 2021 at 5:42:41 AM UTC-4 tapi...@gmail.com wrote:
>>>
>>>> On Sunday, May 23, 2021 at 4:51:30 AM UTC-4 tapi...@gmail.com wrote:
>>>>
>>>>> In the following code, "make([]T, n)" is reported as escaped.
>>>>> But does it really always escape at run time?
>>>>> Does the report just mean "make([]T, n) possibly escapes to heap"?
>>>>>
>>>>> package main
>>>>>
>>>>> type T int
>>>>>
>>>>> const K = 1<<13
>>>>> const N = 1<<12
>>>>> var n = N
>>>>> var i = n-1
>>>>>
>>>>> func main() {
>>>>> var r = make([]T, N) // make([]T, N) does not escape
>>>>> println(r[i])
>>>>>
>>>>> var r2 = make([]T, n) // make([]T, n) escapes to heap
>>>>> println(r2[i])
>>>>>
>>>>> var r3 = make([]T, K) // make([]T, K) escapes to heap
>>>>> println(r3[i])
>>>>> }
>>>>>
>>>>
>>>> Another question is, why should "make([]T, K)" escape to heap?
>>>> Using the capacity as the criterion is not reasonable.
>>>> After all arrays with even larger sizes will not allocated on heap.
>>>>
>>>
>>> It looks, capacity is not only criterion. Whether or not there is a
>>> pointer referencing the allocated elements is another factor.
>>> In the following program, if K is changed to "1<<12", then no escapes.
>>>
>>> But, this is still not reasonable.
>>>
>>> package main
>>>
>>> const K = 1<<13
>>> var i = K-1
>>>
>>> func main() {
>>> var x = new([K]int) // new([8192]int) escapes to heap
>>> println(x[i])
>>>
>>> var y [K]int // not escape
>>> println(y[i])
>>>
>>> var z = [K]int{} // not escape
>>> println(z[i])
>>>
>>> var w = &[K]int{} // &[8192]int{} escapes to heap
>>> println(w[i])
>>> }
>>>
>>>
>>>>
>>>>
>>> --
>>>
>> 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.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/571020ba-89c4-4de6-8eba-17d46b20ce42n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/571020ba-89c4-4de6-8eba-17d46b20ce42n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b78084a6-518a-4444-ab04-f0fd4c095a9an%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/b78084a6-518a-4444-ab04-f0fd4c095a9an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfECd549Gfij-2JOsdNQC3hkExykXJp-Vf2F11PFKErT%2Bg%40mail.gmail.com.
