On Sunday, May 23, 2021 at 8:08:30 AM UTC-4 axel.wa...@googlemail.com wrote:
> 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
>
I don't argue whether or not large values shouldn't always live on the
stack is a good idea. I think the current implementation is some
unreasonable for its inconsistency. If large values shoudn't live on stack,
then make all large values not live one stack. The current implementation
put some large values on stack, but others not, whereas all these large
values could be safely put on stack.
> 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.
>
Whether or not there is a header is also not the absolute criterion used in
the current implementation. This is another inconsistency.
Some values with header are allocated on stack, but some others are on
heap, whereas all of them are safely to be put on stack.
The criterions used in the current implementation are large values with
headers are put on heap.
I don't try to make criticisms here. I just seek a reasonable explanation
for this implementation.
>
> 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 <tapi...@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...@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/f522b85c-9116-4f18-8aac-c3a41dcacf32n%40googlegroups.com.
