On Sunday, May 23, 2021 at 8:58:12 AM UTC-4 axel.wa...@googlemail.com wrote:
> 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. > Yes. I don't expect there must be an answer. I just show some weird things. Maybe the info is helpful for someone. ;D > > >> >> >>> >>> 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...@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/5c9fefa3-6f64-43bb-bf5a-8b534eca3a9an%40googlegroups.com.
