Walter Bright:
Thank you for your answers Walter, as you guess I am ignorant
about segmented stacks.
The trouble with segmented stacks are:
1. they have a significant runtime penalty
Also, they do not save RAM, they save address space. RAM is not
committed until a stack memory page is actually used.
Regarding performance and memory used they say:
http://golang.org/doc/go_faq.html#goroutines
The result, which we call goroutines, can be very cheap: unless
they spend a lot of time in long-running system calls, they cost
little more than the memory for the stack, which is just a few
kilobytes. To make the stacks small, Go's run-time uses
segmented stacks. A newly minted goroutine is given a few
kilobytes, which is almost always enough. When it isn't, the
run-time allocates (and frees) extension segments automatically.
The overhead averages about three cheap instructions per
function call. It is practical to create hundreds of thousands
of goroutines in the same address space. If goroutines were just
threads, system resources would run out at a much smaller
number.<
Segmented stacks are useful for 32 bit address space. However,
they are not useful for 64 bit address spaces.
I think Go is meant to be used mostly on 64 bit servers.
Both the designers of Go and Rust are experienced people, and
they plan to use their languages on 64 bit systems.
Here they say Go avoid many stack overflows, because stack are
limited by the available virtual memory:
http://stackoverflow.com/questions/4226964/how-come-go-doesnt-have-stackoverflows
I think LLVM supports segmented stacks, the example given is on
x86-64:
http://llvm.org/releases/3.0/docs/SegmentedStacks.html
Bye,
bearophile
