runtime: allow no-escape slices of unknown capacity to be allocated to the stack more aggressively

[fredbi]

Context

Whenever a slice is allocated with a variable capacity (e.g. make([]int, 0, n)), the compiler concludes it escapes to the heap,
even though the slice does not actually escape.

Examples:

func sliceAllocInt(n int) int {
	index := make([]int, 0) // does not escape, even though the append makes it allocate on the heap

	for i := 0; i < n; i++ {
		index = append(index, i)
	}

	return len(index)
}

func sliceAllocMakeInt(n int) int {
	index := make([]int, n) // escapes, since n is unknown

	for i := 0; i < n; i++ {
		index[i] = i
	}

	return len(index)
}

func sliceAllocMakeConstInt(_ int) int {
	const size = 32
	index := make([]int, size) // does not escape: size is known at build time: correctly allocated to the stack

	for i := 0; i < size; i++ {
		index[i] = i
	}

	return len(index)
}

Notice that this contrasts with escaping conclusions about similar constructs with maps:

• snippet (i) no escape, but will allocate on the heap because of the need to grow
• snippet (ii) escape (even if it actually doesn't), because the capacity to allocate is not known at build time
• snippet (iii): no escape & alloc on the stack as expected

Proposal

I propose to adopt a more aggressive strategy to allocate slices on the stack whenever possible,
whether the capacity is known at build time or not.

Snippet (ii) should be detected as no escape (I believe it is at some point, and we revert to escaping because of the
variable capacity). This would make the escape analysis consistent with maps.

The decision to allocate non-escaping slices to the stack or to the heap should be deferred to runtime,
favoring stack whenever the capacity fits and resorting to heap only for the larger slices.

At the very least, this should favor well-abiding functions that provide a predictable capacity in the call to make (such as snippet (ii)). Growing dynamically the slice is probably a case we could still leave to the heap.

[fredbi]

See also a related proposal regarding maps: #58214

[randall77]

Currently all of our stack frames are fixed size, so allocating anything of dynamic size on the stack is a big project.

You can simulate what you want like this:

	index := append(make([]int, 0, 64), make([]int, n)...)

That will stack-allocate if n <= 64 and heap allocate otherwise.

I guess we could do that transformation automatically, but we'd need to know the right number for 64, which I think depends on the application.

[randall77]

Taking out of the proposal process, as this is just an optimization. There's no new API.

[mknyszek]

To add on to what @randall77 said, we briefly considered some kind of off-stack-but-bound-to-stack-frames allocator for dynamically-sized things (and other things that escape for some of the more "trivial" reasons), but the total win is unclear when there are workarounds that applications are using (like what @randall77 pointed out).