This is a speculative idea from discussion with @aclements. Jotting it down so it doesn't get lost and to open discussion.
Spinning off many goroutines that grow their stack and then exit can be a source of performance pain. See e.g. #18138. One approach to fixing this is tracking and using statistics about stack growth behavior per spawn site.
Another possible approach is to:
- switch immediately in the scheduler from parent goroutine to spawned goroutine
- use the (free part of) the parent's stack as the spawn's stack
- relocate the spawn's stack as needed
The idea here is that the parent goroutine's stack is likely to have plenty of free space, so if the spawn is short-lived, we can avoid doing any stack allocation for it at all, much less multiple stack growths.
If the spawn lives long enough that the parent goroutine starts running again, then this is worse. So it might be worth tracking some basic statistics on the fly to decide whether to do this.
This is a speculative idea from discussion with @aclements. Jotting it down so it doesn't get lost and to open discussion.
Spinning off many goroutines that grow their stack and then exit can be a source of performance pain. See e.g. #18138. One approach to fixing this is tracking and using statistics about stack growth behavior per spawn site.
Another possible approach is to:
The idea here is that the parent goroutine's stack is likely to have plenty of free space, so if the spawn is short-lived, we can avoid doing any stack allocation for it at all, much less multiple stack growths.
If the spawn lives long enough that the parent goroutine starts running again, then this is worse. So it might be worth tracking some basic statistics on the fly to decide whether to do this.