Thanks for the explanations. I agree on them mostly.
But the println call doesn't make x escape, so I think println is not the
root cause making y escape.
In fact, I'm surprised that y doesn't escape without the last println call.
It looks gc is so smart that it translates "*y" to the value referenced by
y at compile time.
However, with the last println call, gc becomes less smart by disabling the
translation.
The following is the instructions generated for "*y++" with and without the
last println call.
// Without the last println call.
0x001d 00029 (main.go:12) MOVQ "".y+24(SP), AX
0x0022 00034 (main.go:12) INCQ (AX)
// With the last println call.
0x001d 00029 (main.go:12) MOVQ "".&y+24(SP), AX
0x0022 00034 (main.go:12) MOVQ (AX), AX
0x0025 00037 (main.go:12) INCQ (AX)
On Tuesday, June 1, 2021 at 10:26:04 AM UTC-4 Jan Mercl wrote:
> On Tue, Jun 1, 2021 at 3:52 PM tapi...@gmail.com <tapi...@gmail.com>
> wrote:
>
> By default, any local variable that has its address taken and that
> address can outlive the function execution forces the variable to
> escape, quite naturally as the stack frame with the variable is
> destroyed upon returning from the function.
>
> Then there are, or could be, some special cases, where the compiler
> can prove it is not necessary. It's possible the compiler cannot prove
> much about a special function like 'println` that may, for example,
> never exists in SSA form etc.
>
> The last statement in main can be somewhat special wrt escape
> analysis, but that depends on implementation details, so in the
> general case the answer to the topic question is IMO 'yes'.
>
--
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/81f0e194-5e74-44e8-978c-f02749da6f59n%40googlegroups.com.
