memory management, limited lifespan of goroutines

[justjoeactually]

A goroutine's stack can increase the size of memory but never decreases, is there any interest in a feature to limit the lifespan of a goroutine to avoid rising memory consumption because each worker increases stack memory size for one execution but doesn't need to keep it forever? Simple implementations are a limited execution counter or a time to live.

[alitto]

Hey @justjoeactually, that's a good point.
What you mention is true, a goroutine's stack can be expanded if necessary but it's never shrinked. However, the total number of active frames in a given stack (which indicates how much of the stack's reserved space is actually in use) for a particular goroutine depends on the number of nested function calls inside of it rather than the number of function calls performed by it during its lifecycle. In other words, stack size is not proportional to the amount of time a goroutine has been running.
Worker goroutines are essentially a for loop which executes tasks passed via a channel as anonymous functions in a sequential manner, therefore, the max level of nesting is dictated by the tasks passed to it. If you create a worker pool and pass it a function with a very deep nesting level (e.g. a recursive function) then the stack size of the worker that picks it up may indeed need to grow to be able to invoke the passed function, but once that function is completed, all its frames will be reused to invoke the next tasks, so it wouldn't grow indefinitely.
I don't think this could be a major issue in most use cases, but please feel free to send any examples that could be problematic.
Adding a counter to each worker goroutine comes at a cost (extra memory allocation + increment operation) so I'd prefer to avoid it for now.

Thank you!

Here's an article that does a great job explaining stacks and frames: https://www.ardanlabs.com/blog/2017/05/language-mechanics-on-stacks-and-pointers.html