How Stacks are Handled in Go

At CloudFlare, the use of Go language is prevalent for various services and applications. One significant feature of Go is goroutines, which are low-cost, cooperatively scheduled threads used in tasks like timeouts, generators, and racing multiple backends against each other. To ensure that goroutines consume minimal memory while being easy to start with minimal configuration, the Go runtime manages stacks differently than traditional languages like C. In C, when a thread is started, the standard library allocates a block of memory for its stack and informs the kernel about it. However, if this block isn't enough, increasing the size across all threads can lead to wastage of memory. Deciding stack size per thread makes creating threads more complex. Go tackles this issue by dynamically providing goroutines with the stack space they need on demand, relieving programmers from making decisions about stack size. Initially, Go used segmented stacks where a new 8 KB section of memory was allocated for each goroutine's stack and expanded when needed through stack splitting. However, this approach had a flaw known as the hot split problem, which led to expensive stack shrinking operations. To address this issue, Go switched to stack copying, where a new segment with double the size is created and old segments are copied into it. This makes stack shrinking free and eliminates the need for any further action when the stack grows again. However, managing pointers within the stack during its movement poses a challenge that can be overcome by leveraging garbage collection information. The Go team is currently rewriting large parts of the runtime in Go to enable concurrent garbage collection in the future and improve stack management. Despite potential alternatives like allocating large sections of virtual memory, these come with their own set of challenges. Overall, a significant amount of effort has been invested into making goroutines efficient and suitable for most tasks.