Memory footprint of a goroutine?

Getting Help
1

Hi fellow gophers,

What is the memory footprint of a goroutine ? Here is a quote:

A newly minted goroutine is given a few kilobytes, which is almost always enough.
When it isn’t, the run-time grows (and shrinks) the memory for storing the stack auto‐
matically, allowing many goroutines to live in a modest amount of memory

So it starts with a few kilos (how many ?) then it grows and shrinks automatically.

What are the rules for growing and shrinking ? Does it double its size, does it get 50% more memory whenever it needs more memory ?

Similarly, what are the rules for shrinking ? When is shrinking done, I assume after a GC cycle has removed enough memory so that its total footprint is smaller than a threshold, what is that threshold ?

Also, what performance costs are created by a goroutine that often increases and decreases its memory footprint ?

1 Like
2

Where did you get that quote from? I can not find it in the languages specification.

And the quote reads as if those few kilos are for the stack only, while the heap remains shared between goroutines.

3

I found this article that explores goroutine memory usage in detail. The article points to stack.go that defines the minimum stack size as 2048 bytes. (You can always check the file in the main branch to see if this value is still the same.)

1 Like
4

How long is a piece of string?
The memory taken by a Goroutine depends on what it does, i.e. how much memory it allocates, and how deep its callstack is.

5

Hi @amnon

Obviously the memory needed by a goroutine depends on what it does. But the question is about how it scales:

my goroutine has X memory allocated now, it needs more thus its get allocated more memory Y. What is the relation between X and Y ?

my goroutine has X memory allocated now, it needs less thus its get allocated less memory Y. What is the relation between X and Y ?

6

All the Goroutines share the same pool of garbage collected memory. So the Garbage Collector will recycle inaccessible objects when it runs, irrespective of which goroutine allocated the object.

1 Like
7

hi @ammon,

Somehow I feel puzzled, I though GC only cleans the heap while it does not touch the stack. How does this play into goroutines ?

8

GC does not mutate the stack.
But it does scan the stack for references.

9

thank you @amnon , I now understand what you mean, and realize that I should formulate my question a bit better:

How will the stack memory consumed by a given goroutine fluctuate ?

  • a goroutine X starts with an initial stack memory of 2048 bytes, and if that goroutine is already using 2048 bytes and wants to use one extra byte more, what happens next ?
  • similarly, another goroutine Y is using now 2049 bytes of stack memory, but suddenly it no longer needs 50% of those bytes, how will the stack look like then ?
10

From the ultimate documentation at - The Go Programming Language

Line 950: // Stack growth is multiplicative, for constant amortized cost.

Line 1192 (in func shrinkstack): newsize := oldsize / 2

1 Like
11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.