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 [email protected] <[email protected]> wrote: > > > On Sunday, May 23, 2021 at 5:42:41 AM UTC-4 [email protected] wrote: > >> On Sunday, May 23, 2021 at 4:51:30 AM UTC-4 [email protected] 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEQx2CoMAPqNDOddz48G9u1VkLGwv1zaZJ27Qh83SoqkA%40mail.gmail.com.
