cmd/compile: function signature based optimizations

[mateusz834]

It is widely known that passing anything to an interface method call with arguments that contain pointers causes heap allocations of that value. This happens because the compiler’s escape analysis cannot prove that the call would not cause the values to be escaped. Even though we don't know exactly which function is going to be called, there is one thing that we know at the caller site: the signature of the function being called. Using that fact, the compiler could collect all functions with the same function signature, run escape analysis over them and then use the per-signature result to decide whether dynamic dispatch calls need to have the arguments escaped. You can think of this as a fallback. Currently the fallback is to heap allocate, with this approach, if none of the functions with the same signature cause their arguments to escape, then dynamic dispatch calls would not require heap allocation either.

If this was implemented in the compiler I would expect a reduced heap allocations count in most programs, some examples:

• The byte slice passed to io.Reader/io.Writer would likely not need to be allocated on the heap.
• Arguments passed to http.Handler to be stack allocated (they are often wrapped, especially the http.ResponseWriter).
• Log functions in log/slog would not cause allocations, and the optimization in slog.Record would not be really needed anymore:
  

  go/src/log/slog/logger.go

  Lines 271 to 272 in 215de81

  	r := NewRecord(time.Now(), level, msg, pc)
  	r.AddAttrs(attrs...)

  
  

  go/src/log/slog/record.go

  Lines 38 to 50 in 215de81

  	// Allocation optimization: an inline array sized to hold
  	// the majority of log calls (based on examination of open-source
  	// code). It holds the start of the list of Attrs.
  	front [nAttrsInline]Attr
  	// The number of Attrs in front.
  	nFront int
  	// The list of Attrs except for those in front.
  	// Invariants:
  	// - len(back) > 0 iff nFront == len(front)
  	// - Unused array elements are zero. Used to detect mistakes.
  	back []Attr

  
  It is also worth noting that log/slog API would likely not need the Enabled() method if this kind of optimization was present:
  

  go/src/log/slog/handler.go

  Lines 31 to 41 in 215de81

  	type Handler interface {
  	// Enabled reports whether the handler handles records at the given level.
  	// The handler ignores records whose level is lower.
  	// It is called early, before any arguments are processed,
  	// to save effort if the log event should be discarded.
  	// If called from a Logger method, the first argument is the context
  	// passed to that method, or context.Background() if nil was passed
  	// or the method does not take a context.
  	// The context is passed so Enabled can use its values
  	// to make a decision.
  	Enabled(context.Context, Level) bool

• This would reduce the amount of people reaching for sync.Pool (proposal: net/http: add Request.CopyTo #68501)

Obviously, this would not work in all cases and has some drawbacks, it only takes one function to force heap allocation of other dynamic dispatch calls (of functions with same signature). This might easily prevent signatures based solely on basic types from benefiting from this optimization, say: func(b []byte) { go func ( /* do sth with b */ }, so folks might pollute functions with some unused and unneeded parameters just to make this optimization work: func(b []byte, _ ...struct{}). This optimization would be beneficial for signatures that take/return custom (package-local) types, like log/slogs Handle(context.Context, slog.Record) error.

This is just an idea that came to my mind while reading #62653. I'm not even sure whether this change is rational, because changes in the escape analysis results would most likely require the dependencies to be recompiled, changes to the cache and probably some other stuff that I am not even aware of.

The no-copy string -> []byte optimization could also take benefit from this kind of optimization.

CC @golang/compiler

[gabyhelp]

Related Issues

• cmd/compile: avoid always escaping the receivers in interface method calls #62653
• cmd/compile: avoid allocations for some return values #22081
• proposal: Go 2: type annotation `~` for stack allocated variables #37346 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

Unfortunately this kind of thing really requires whole-program analysis, which we are loth to do (because Go should scale to really large codebases).
It also runs afoul of the plugin package and maybe one day, reflect or similar things (#16522, #4146, #21670, #47487) that can make interfaces dynamically.

[mateusz834]

It also runs afoul of the plugin package and maybe one day, reflect or similar things (#16522, #4146, #21670, #47487) that can make interfaces dynamically.

It of course can be turned off for packages importing the plugin package, it is not used that much.

[Jorropo]

Currently we do backward escape analysis.
Ideally with perfect forward and backward escape analysis when we see a virtual call we would look up down left and right in the call stack to find out exactly which are the possible implementations and do the best given all the possible implementations.
Instead you are proposing that we would assume it could be any method in the program on a type that implement the interface which is probably simpler, even simpler to do incrementally (useful caches for similar programs).

So let's say all the implementations of io.Writer in your program do not leak, any call to io.Writer would not leak.
However this is quite an unpredictable optimization regime, importing a new library, on a completely unrelated piece of code could then impact the results of escape analysis everywhere.
Import time side effects are not usually a good thing, and this would be like import time side effect but for performance, and it's everywhere, and you can't grep for it.
For example simple interfaces like io.Writer if you somehow import io anywhere (which you almost certainly do) it would leak since it would match io.Pipe which leaks.

[adonovan]

the compiler could collect all functions with the same function signature

As Keith said, the compiler can see only the functions in the current package (plus summaries of their transitive dependencies), but it cannot predict what is to come in packages higher up within the build. So, this kind of optimization is limited to a single compilation unit. For example, if an interface method is foo(bar), where both the method name foo and the parameter type name bar are unexported, the compiler can safely assume that all implementations of that method reside in the same package, and simplify accordingly. (Although a type from a higher-level package may also have a foo(bar) method thanks to embedding, the implementation of that method must be defined in the same package as foo.)

[mateusz834]

if an interface method is foo(bar), where both the method name foo and the parameter type name bar are unexported, the compiler can safely assume that all implementations of that method reside in the same package, and simplify accordingly.

Not sure about that, you can use type inference to hack that is some edge cases:

package foo

type bar struct{ a [128]byte }

type iface interface {
	foo(*bar)
}

type fooImpl func(*bar) *bar

func (f fooImpl) foo(b *bar) { f(b) }

func Iface(f func(b *bar) *bar) {
	var iface iface = fooImpl(f)
	iface.foo(&bar{})
}

package main

import (
	"aa/foo"
	"runtime"
)

func Val[T any](t T) T {
	go func() {
		runtime.KeepAlive(t)
	}()
	return t
}

func main() {
	foo.Iface(Val)
}

[adonovan]

Yeah, I realized just after hitting send that the my mention of the parameter type bar was a distracting irrelevance because you don't need to name a type to create values of it: the name of the method is all that matters and all that the compiler can count on.

In any case, in your example, the call iface.foo(&bar{}) must nonetheless dispatch to an implementation of method foo in the same package: in this case, there is only one.

BTW I'm not sure what go func() { KeepAlive(t) } () is supposed to achieve: it doesn't ensure anything about the lifetime of t.

[mateusz834]

BTW I'm not sure what go func() { KeepAlive(t) } () is supposed to achieve: it doesn't ensure anything about the lifetime of t.

My idea was: In package foo signature func(*bar) *bar does not force allocations, but the Val[T] from main would cause such (The reason for a goroutine was to force an allocation).

[adonovan]

My idea was: In package foo signature func(*bar) *bar does not force allocations, but the Val[T] from main would cause such (The reason for a goroutine was to force an allocation).

A Go compiler is free to optimize away the goroutine entirely since it has no dependable consequence. Even assuming Val's parameter does escape, I don't think it changes anything: the key point is that iface.foo is a reference to the abstract method foo, whose concrete implementation's source (even if generic) must reside in the same package.

[mateusz834]

A Go compiler is free to optimize away the goroutine entirely since it has no dependable consequence.

This is now offtopic, but shouldn't runtime.KeepAlive guarantee that it would not be eliminated? Based on the comment i would assume so:

Introduce a use of x that the compiler can't eliminate.

go/src/runtime/mfinal.go

Lines 568 to 575 in a704d39

	func KeepAlive(x any) {
	// Introduce a use of x that the compiler can't eliminate.
	// This makes sure x is alive on entry. We need x to be alive
	// on entry for "defer runtime.KeepAlive(x)"; see issue 21402.
	if cgoAlwaysFalse {
	println(x)
	}
	}