From 287967f74c9d937b1075a648be5fd9247283cef6 Mon Sep 17 00:00:00 2001 From: Rob Pike Date: Fri, 21 Mar 2014 13:59:30 +1100 Subject: [PATCH] doc/go_faq.html: update description of stack management They aren't segmented any more, at least with gc. Also improve the comparison of goroutines and threads. Fixes #7373. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/77950044 --- doc/go_faq.html | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/doc/go_faq.html b/doc/go_faq.html index fb2d929bd69..9606213b1f3 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -426,18 +426,20 @@ When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won't be blocked. The programmer sees none of this, which is the point. -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. +The result, which we call goroutines, can be very cheap: they have little +overhead beyond 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 +To make the stacks small, Go's run-time uses resizable, bounded 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. +When it isn't, the run-time grows (and shrinks) the memory for storing +the stack automatically, allowing many goroutines to live in a modest +amount of memory. +The CPU 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 +address space. +If goroutines were just threads, system resources would run out at a much smaller number.

@@ -1614,9 +1616,10 @@ it now. Gccgo's run-time support uses glibc. Gc uses a custom library to keep the footprint under control; it is compiled with a version of the Plan 9 C compiler that supports -segmented stacks for goroutines. -The gccgo compiler implements segmented -stacks on Linux only, supported by recent modifications to the gold linker. +resizable stacks for goroutines. +The gccgo compiler implements these on Linux only, +using a technique called segmented stacks, +supported by recent modifications to the gold linker.