Is Go's stack split or stack copy?

Question

I'm interested in Go's stack management. I searched various data but it confuses me because all data is different. What I am curious about is whether golang's stack management is stack splitting or stack copying.

What is the correct answer?

golang version: go1.16.3

Answer 1

Stack splitting vs. stack copying is not so much a language feature—the language spec makes no mention of either strategy—as it is a design choice in implementations of the language, of which there are several. Therefore, as pointed out by Flimzy in his comment, you should specify which implementation you're referring to in your question.

---

As of Go 1.4, the "canonical" Go compiler (known as gc) no longer splits stacks and now uses stack copying:

Stacks are now contiguous, reallocated when necessary rather than linking on new "segments"; this release therefore eliminates the notorious "hot stack split" problem.

Brad Fitzpatrick (former member of the Go team) explains some of the problems that stack splitting caused in the Go compiler in his Gophercon India 2016 (at mark 12'50''):

[...] in Go, you have goroutines, which is like a really, really lightweight thread that has a stack that's small and it grows as necessary. The way it used to work is little goroutines with little stacks and, when you ran out of stack space, you would make another stack somewhere else and you would be jumping between these stacks as you called functions and returned. Which was great most of the time until it wasn't, until you were in a tight loop, in something like a JPEG decoder or something, and you were bouncing between stacks and you had really big performance penalties that we're surprising. And then you would move some code somewhere else and your performance characteristics would change a lot.

---

As for gccgo (an alternative implementation of the Go language), Ian Lance Taylor explains that it uses stack splitting in this 2010 paper (section 7.4) and this 2016 thread; Keith Randall also provides some insight about this design choice in another thread.