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

diff --git a/doc/go_faq.html b/doc/go_faq.html
index fb2d929bd69fd4ca3c5571b737692e70edf25573..9606213b1f332515602d3b90c7042e3e69ca5261 100644 (file)
--- 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.
 </p>
 
 <p>
-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.
 </p>
 
@@ -1614,9 +1616,10 @@ it now. <code>Gccgo</code>'s run-time support uses <code>glibc</code>.
 <code>Gc</code> 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 <code>gccgo</code> compiler implements segmented
-stacks on Linux only, supported by recent modifications to the gold linker.
+resizable stacks for goroutines.
+The <code>gccgo</code> compiler implements these on Linux only,
+using a technique called segmented stacks,
+supported by recent modifications to the gold linker.
 </p>
 
 <h3 id="Why_is_my_trivial_program_such_a_large_binary">