On Sat, Nov 21, 2020 at 12:11 AM jfcg...@gmail.com <jfcga...@gmail.com> wrote:
>
> I have the following:
>
> package myf
>
> func F1(x *int, ch chan bool) {
> *x += 1
> ch <- false
> }
>
> func F2() {
> var x int
> ch := make(chan bool) // or with buffer
> go F1(&x, ch)
> <-ch
> }
>
> I get this when I build with go 1.15.5 via go build -gcflags '-m -m' :
>
> 3:6: can inline F1 with cost 7 as: func(*int, chan bool) { *x += 1; ch <-
> false }
> 8:6: cannot inline F2: unhandled op GO
> 3:9: x does not escape
> 3:17: ch does not escape
> 9:6: x escapes to heap:
> 9:6: flow: {heap} = &x:
> 9:6: from &x (address-of) at ./heap.go:11:8
> 9:6: from F1(&x, ch) (call parameter) at ./heap.go:11:7
> 9:6: moved to heap: x
>
> So x is allocated on the heap and needs gc when F2() returns. I know F2()
> will wait for F1() and passing &x is safe if it was local. So how can I tell
> this to go compiler and avoid allocation/gc costs? Do we need a new go:local
> directive to mark such variables?
It would help to have a more realistic example. I don't yet see any
reason why people would write code like this, so it doesn't seem worth
optimizing.
If something like this is worth optimizing, the first thing to look
into would be whether the compiler's escape analysis can improve to
handle that case. A go:local directive seems very easy to misuse, and
doesn't seem like a good fit for the Go language.
Ian
--
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/CAOyqgcVnXsh0hRXuUe%2BdxMdxyeYhMMf7YuOdTsqg3YPdZWrJaw%40mail.gmail.com.
