Depends what you mean by “large”. As of 1.24 Go will put slices several KB into the stack frame:
make([]byte, 65536)
make([]byte, 65537)
Interestingly arrays have a different limit: they respect MaxStackVarSize, which was lowered from 10MB to 128 KB in 1.24.
If you use indexed slice literals gc does not even check and you can create megabyte-sized slices on the stack.
// -smallframes
// ir.MaxStackVarSize = 64 * 1024
// ir.MaxImplicitStackVarSize = 16 * 1024
a := [64 * 1024 +1]byte{}
b := make([]byte, 0, 16 * 1024 +1)
// default
// MaxStackVarSize = int64(128 * 1024)
// MaxImplicitStackVarSize = int64(64 * 1024)
c := [128 * 1024 +1]byte{}
d := make([]byte, 0, 64 * 1024 +1)
test/test.go:36:2: moved to heap: c
[]byte{N: 0}The initial stack size seems to be 2kb, a more on a few systems. So far I understand you can allocate a large local i.e. 8kb, that doesn't escape and grow the stack immediately. (Of course that adds up if you have a chain of calls with smaller allocs). So recursion is certainly not the only concern.
I am pretty sure the escape analysis doesn't affect the initial stack size. Escape analysis does determine where an allocation lives. So if your allocation is lower then what escape analysis considers heap and bigger then the initial stack size, the stack needs to grow.
What I am certain about, is that I have runtime.newstack calls accounting for +20% of my benchmark times (go testing). My code is quite shallow (3-4 calls deep) and anything of size should be on the heap (global/preallocated) and the code has zero allocations. I don't use goroutines either, it might me I still make a mistake or it's the overhead from the testing benchmark. But this obviously doesn't seem to be anything super unusual.