Any plan on improving Go's escape analysis?

[bronze man]

When I call `fmt.Println(1,2) `, I expect all the interfaces of the arguments should alloc on stack so that the garbage collection part will use less cpu time, but currently it is alloc on heap.Because I found that I do not need that alloced valuable (interface{})(1) is not used after this function call.

Do you guys have any plan on improving those stuff?

Is this kind of problem too hard to be solved in linear time?

Or is there any plan that the developer of package "fmt" can add "//go:noescape" and "unsafe" to mark that all the interfaces of the arguments should alloc on stack?("//go:noescape" can only add to asm function right now.)

[T L]

Do you use "go build -gcflags=-m" to check if the arguments are alloced on heap or stack?

I guess the result of "go build -gcflags=-m" may be not accurate.
For your simple example, `fmt.Println(1,2) `, I think the compiler does alloc the interfaces of the arguments on stack.
The reason is the real data in the interfaces can be represented with one word.
If the real data must be represented with more than one word, than real data part of the interface values will be alloced on heap (but the two pointer fields of the interfaces should be still alloced on stack).

This is just my understanding, it may be not right.


 

[Ian Lance Taylor]

On Sat, Oct 1, 2016 at 12:47 AM, bronze man <bronz...@gmail.com> wrote:
> When I call `fmt.Println(1,2) `, I expect all the interfaces of the
> arguments should alloc on stack so that the garbage collection part will use
> less cpu time, but currently it is alloc on heap.Because I found that I do
> not need that alloced valuable (interface{})(1) is not used after this
> function call.
>
> Do you guys have any plan on improving those stuff?
>
> Is this kind of problem too hard to be solved in linear time?

There are improvements to the compiler's escape analysis in every release.

Go is free software. We welcome contributions from anybody.

Ian

[Aliaksandr Valialkin]

fmt.* functions may call Stringer and Formatter interface methods for the passed arguments, so the arguments may escape when calling these methods.

Probably, conditional escaping may be implemented for function argument. For example of fmt.*, escape only arguments implementing Stringer or Formatter interfaces when passing them to fmt.Println. Furthemore, such arguments may be left on stack if the corresponding Stringer and Formatter methods don't escape the argument.

[Jesper Louis Andersen]

On Sat, Oct 1, 2016 at 6:45 PM, Ian Lance Taylor <ia...@golang.org> wrote:

There are improvements to the compiler's escape analysis in every release.

Also, escape/representation analysis is approximate in nature. So you can't easily detect all variants of this and have the compiler optimize them. A compiler tend to become stronger at this as time passes. But it also affects compilation time, so there is a point at which additional analyses has bad cost/benefit.

OTOH, escape analysis has other uses than moving things on the stack. If you can prove you are the only holder of a Mutex for instance, you can elide the Mutex. This is useful because you can write thread-safe code in your stdlib but essentially get the single-threaded variant for single-threaded programs.

--

J.

[David Chase]

One thing to know about Go's escape analysis is that it works bottom up, package by package, so it does use interprocedural information.

Right now that information is pretty coarse, on the level of "escapes", "content escapes", and "[content] transmitted to result N".

For a parameter with interface type, one way of augmenting that might be to not automatically give up upon seeing an invokeinterface, but instead to list the interface methods applied to the value (e.g., "String()").  This is also a problem where there is no dishonor in taking hacky shortcuts, so we might only record PARAM.method(...) instances, and still punt for P2 given an expression like P1.method(P2).