How come Go doesn't have stackoverflows

I read in this presentation http://golang.org/doc/ExpressivenessOfGo.pdf page 42:

>Safe
>
>- no stack overflows

How is this possible? and/or how does Go works to avoid this?

It's a feature called "segmented stacks": every goroutine has its own stack, allocated on the heap.

In the simplest case, programming language implementations use a single stack per process/address space, commonly managed with special processor instructions called push and pop (or something like that) and implemented as a dynamic array of stack frames starting at a fixed address (commonly, the top of virtual memory).

That is (or used to be) fast, but is not particularly safe. It causes trouble when lots of code is executing concurrently in the same address space (threads). Now each needs its own stack. But then, all the stacks (except perhaps one) must be fixed-size, lest they overlap with each other or with the heap.

Any programming language that uses a stack can, however, also be implemented by managing the stack in a different way: by using a list data structure or similar that holds the stack frames, but is actually allocated on the heap. There's no stack overflow until the heap is filled.

it uses a segmented stack. Which basically means it uses a linked list instead of a fixed size array as it's stack. When it runs out of space it makes the stack a little bigger.

edit:

Here is some more information: http://golang.org/doc/go_faq.html#goroutines

The reason this is so great is not because it'll never overflow (that's a nice side-effect), it's that you can create threads with a really small memory footprint, meaning you can have lots of them.

I don't think they can "totally" avoid stack overflows. They provide a way to prevent the most typical programming-related errors to produce a stack overflow.

When the memory finishes there is no way to prevent a stack overflow.

Even C can do it with a few constraints that basically affect the compiler.

It is an impressive feat of engineering but not of language design.

I think what they are referring to here is that access to arrays is always checked against the actual length of the array, thus disabling one of the most common ways by which C programs crash accidentally or are crashed maliciously.

For example:

package main

func main() {
	var a [10]int
	
	for i:= 0; i < 100; i++ {
		a[i] = i
	}
}

will panic with a runtime error when it tries to update the non-existent 11th element of the array. C would scribble over the heap, and probably also crash but in an uncontrolled way. Every array knows its length. In some cases there will be scope for the compiler to optimize out the checks if it can prove they are not necessary. (Or a sufficiently smart compiler could perhaps statically detect a problem in this function.)

Many of the other answers are talking about the memory layout of the stack but this is really not relevant: you can have heap overflow attacks too.

Basically Go's pointers should always be typesafe, with arrays and other types, unless you specifically use the unsafe package.