There's lots of issues about resolving interfaces at compile time, so we don't have to allocate their receiver or args: #8618 #18822 #23676 #33160

It's an interesting idea to resolve this at run time instead. Generate code for both cases and decide which allocation path to use.

It can get tricky:

i.Call(&ctx)
j.Call(&ctx)

Then we can only allocate ctx on the stack if both i and j have their Call method marked as not escaping its first argument.

At the time we allocate ctx, we might not know yet which interface methods it might get passed to.

ctx := myCtx{}
... initialize ctx ...
f().Call(&ctx)

Until we can inspect f's return value, we don't know whether ctx escapes.

Sometimes interfaces are wrappers. For example, bufio.NewWriter. When we assign one of those to the io.Writer interface, do we mark its Write method as not escaping its argument? That's a dynamic property of the underlying io.Writer that was passed to NewWriter. How do we associate those things? (We could always punt and be conservative here, but it would be nice to handle.)

More ideas to explore:

1. Each interface method with name XXX can have a counterpart method XXX_escapes() which would return escape flags and possibly any other performance critical information.
   Thus in the example from randall77 with bufio.NewWriter it would simply return the parameters from the underlying interface and the caller could make a decision whether it needs to allocate the structure or use a stack one.

2. Instead of getting these performance critical data before calling the method it might be possible to collect it runtime and store in a cache? What if every interface method call would return something we could cache in a map[{interface,method}]perfAndEscapeData ?
   it can be per-goroutine cache, potentially invalidated on GC, but still..

3. We can instantiate shadow interface instance for a given one with non-nil methods for all unescaping ones. This shadow interface vtable can be filled run-time by methods themselves in their epilogue code when they are sure about their own properties (and all sub-callers are non escaping too).

Ofcause it is quite tricky and 2 and 3 require internal sub interface pointers in bufio.Writer to stay consistent and do not change to anything but nil. Probably it requires a huge logic in the compiler :/

Here's another data point.

In this program, we have no allocation for the closure or the potentially-escaped variable:

func foo(x int) {
	call(func() int {
		y := &x
		return *y + 2
	})
}

However, in this similar program that uses an interface value, we have an allocation for both the interface and x:

func foo(x int) {
	call(F(func() int {
		y := &x
		return *y + 2
	}))
}

Issue #8618 tracks the issue about allocating storage for the interface. I think this issue is the right one for tracking escape analysis of the value inside the interface.