In sorty <https://github.com/jfcg/sorty> (commit e4fb296daf1d90037d) I see:
$ go build -gcflags -m |& grep -i heap
./sortyI8.go:319:2: moved to heap: sv
./sortyU8.go:319:2: moved to heap: sv
./sortyF4.go:319:2: moved to heap: sv
./sortyF8.go:319:2: moved to heap: sv
./sortyI4.go:319:2: moved to heap: sv
./sortyLsw.go:338:2: moved to heap: sv
./sortyS.go:319:2: moved to heap: sv
./sortyU4.go:319:2: moved to heap: sv
Local variable sv for synchronization (that I know would be safe to stay
local like the simplified example) escapes to heap. It is the one and only
thing that escapes to heap and I want to get rid of it with something like
*go:local* :)
On Saturday, November 21, 2020 at 5:10:46 PM UTC+3 Ian Lance Taylor wrote:
> On Sat, Nov 21, 2020 at 12:11 AM jfcg...@gmail.com <jfcg...@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/8c8badb4-97b7-4bcf-9bba-5a44272ff1f1n%40googlegroups.com.
