> > I don't try to make criticisms here. I just seek a reasonable explanation > for this implementation. >
As I said, maybe there is one someone else can provide. But I doubt it. I would assume the explanation is "it's a heuristic, written by humans, the implementation of which evolved over a decade - so of course there will be inconsistencies". I also don't think it's productive to demand an explanation - if the current implementation has a flaw (and FTR, I agree that it would make sense to treat `var x = [1<<13]int` and `var x = make([]int, 1<<13)` the same in regards to escape analysis) the solution isn't to explain how it came to be, but to fix it. Which is to say, to file an issue to that effect. That is, after all, how the current implementation came to be in the first place - we started with "everything goes on the heap" and then, little by little, people found cases where it's easy to show that a variable can live on the stack and implemented that analysis. If you just want to understand why the compiler comes to these conclusions (for reasons other than because you think they're flawed) the code is open source <https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go>. I think that would be a reasonable start. Again, to be clear: Maybe someone who knows more about that code is able and willing to provide a better explanation for why it is this way or even a reason why it should be this way. In the meantime, there are other avenues you can explore. > > >> >> 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 > <https://groups.google.com/d/msgid/golang-nuts/f522b85c-9116-4f18-8aac-c3a41dcacf32n%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/CAEkBMfE5_4jd_0G9R5HJ%2B4jY9S0EUFUMpArQ_kXdwnRn1Zhw1w%40mail.gmail.com.
