Skip to content

Commit 287967f

Browse files
committed
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
1 parent 0c84156 commit 287967f

File tree

1 file changed

+13
-10
lines changed

1 file changed

+13
-10
lines changed

doc/go_faq.html

Lines changed: 13 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -426,18 +426,20 @@ <h3 id="goroutines">
426426
the run-time automatically moves other coroutines on the same operating
427427
system thread to a different, runnable thread so they won't be blocked.
428428
The programmer sees none of this, which is the point.
429-
The result, which we call goroutines, can be very cheap: unless they spend a lot of time
430-
in long-running system calls, they cost little more than the memory
431-
for the stack, which is just a few kilobytes.
429+
The result, which we call goroutines, can be very cheap: they have little
430+
overhead beyond the memory for the stack, which is just a few kilobytes.
432431
</p>
433432

434433
<p>
435-
To make the stacks small, Go's run-time uses segmented stacks. A newly
434+
To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly
436435
minted goroutine is given a few kilobytes, which is almost always enough.
437-
When it isn't, the run-time allocates (and frees) extension segments automatically.
438-
The overhead averages about three cheap instructions per function call.
436+
When it isn't, the run-time grows (and shrinks) the memory for storing
437+
the stack automatically, allowing many goroutines to live in a modest
438+
amount of memory.
439+
The CPU overhead averages about three cheap instructions per function call.
439440
It is practical to create hundreds of thousands of goroutines in the same
440-
address space. If goroutines were just threads, system resources would
441+
address space.
442+
If goroutines were just threads, system resources would
441443
run out at a much smaller number.
442444
</p>
443445

@@ -1614,9 +1616,10 @@ <h3 id="How_is_the_run_time_support_implemented">
16141616
<code>Gc</code> uses a custom library to keep the footprint under
16151617
control; it is
16161618
compiled with a version of the Plan 9 C compiler that supports
1617-
segmented stacks for goroutines.
1618-
The <code>gccgo</code> compiler implements segmented
1619-
stacks on Linux only, supported by recent modifications to the gold linker.
1619+
resizable stacks for goroutines.
1620+
The <code>gccgo</code> compiler implements these on Linux only,
1621+
using a technique called segmented stacks,
1622+
supported by recent modifications to the gold linker.
16201623
</p>
16211624

16221625
<h3 id="Why_is_my_trivial_program_such_a_large_binary">

0 commit comments

Comments
 (0)