The problem with EnsureMinStack is that although it can guarantee that upon return there's some free stack space available, there's no guarantee that that much space will be available later. The runtime can take unused stack space back at any time. (Especially with non-cooperative preemption coming.)

I'll have to look into that. Regardless of the specific details, I don't see why we couldn't implement a way to reserve that stack space for the duration of the calling frame (the naive approach would be to mark the calling frame such that unused stack space would not be reclaimed).

As a worst case, this hack could continue to work as long as the compiler doesnt optimize it away or allocate it on the heap (Those are the unspecified behaviours I'm hoping not to be dependent on with EnsureMinStack).

var buf [16 << 10] byte
for i := range buf {
	buf[i] = byte(i)
}

This would enable external FFI (à la rustgo) to take different tradeoffs than cgo by not creating system stacks. Notice how in that blog post I had to lie to the assembler about the frame size of the trampoline.

I am researching this and what it would look like ATM. I plan to come back to this issue with a few ideas for moving forward.

Some thoughts/questions:

1. Each stack has a buffer of around 720 bytes, called StackGuard, seemingly intended for routines running on top of the goroutines' stack like deferproc. Is it a fair assumption that small, hot JITs (ie: ~100 instructions, 16-80 bytes stack or so) could run in a frame (with no defers), and safely eat into this buffer?

2. It looks like the reflect package is doing some magic with stack frame & gc structures. Could we do a similar thing, and mint a new frame + gc bitvector etc, to trick any sweeps that come along to leave our stack alone (for the duration of the frame)?

Instead of runtime.EnsureMinStack, we could have runtime.CallWithMinStackSize (or even put it in the reflect package).