Grow the stack more slowly after an initial stack overflow
As discussed in #19293 (comment 507348) and !10742 (closed), the current default initial stack size of 1k words is so much smaller than the default stack chunk size of 32k words that programs that need just over 1k words of stack trigger a performance pathology. Currently, GHC grows the stack to the full 32k words (which on 64-bit platforms is 256 KiB) as soon as it overflows once, which is a pretty enormous jump.
When a stack is a “small chunk”—that is, less than the default stack chunk size—it seems like it could be more useful to grow the stack in a series of steps rather than all in one go. Perhaps it could double in size until it reaches the full size, for example. One wrinkle here is that it’s not entirely obvious how this should interact with the stack chunk buffer size (-kb
) which normally also defaults to 1k.
A more extreme approach would be to switch away from segmented stacks entirely and simply have a contiguous stack that is copied in full upon stack overflow. This might not be quite as crazy as it sounds: Go made this switch in 2014 and has apparently never looked back. Segmented stacks have a number of performance pathologies that are very difficult to diagnose and even more difficult to actually fix (due to how unpredictable stack usage can be), and issues like #23488 are a symptom.