<p>Segmented stacks are one method to enable the growth of execution stacks in multi-threaded paradigms at runtime, instead of having to statically pre-allocate a fixed-sized stack at compile time.</p>
<p>Some languages including <a href="https://blog.cloudflare.com/how-stacks-are-handled-in-go/" rel="noreferrer">Go</a> and <a href="https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html" rel="noreferrer">Rust</a> at one point in their design considered using segmented stacks for their runtime concurrent stack management. However, they eventually sought other options, partially due to the problem of hot splits.</p>
<p>Hot splits refer to the constant allocation and deallocation of stack memory when a tight loop straddles an allocation boundary. However, it seems to me a way to mitigate the problem is to allocate stack memory as needed, but only deallocate when the stack pointer reaches the previous stack segment. As an example:</p>
<pre><code>|-------| --&gt; |-------| --&gt; |-------|
                             ^SP    New segment just allocated    

|-------| --&gt; |-------| --&gt; |-------|
                     ^SP            New segment still maintained

|-------| --&gt; |-------|
       ^SP                          New segment only now gets deallocated
</code></pre>
<p>While this doesn't resolve the issue of having to jump around in memory at stack boundaries, this does (at least on paper) seem to significantly mitigate the issue of hot swapping without too much extra bookkeeping. Am I missing something? What are some of the other problems with segmented stacks?</p>

<language-design><language-comparison><stack>
Segmented Stack Efficiency
<p>Even if the new segment is maintained, crossing that boundary in a tight loop can be expensive.  The better solution is that when a new segment is allocated, a few frames are moved from the youngest existing segment into the new segment.  Before the segment boundary can be crossed again, those frames have to finish their work.  This trick is a way of introducing hysteresis into the boundary-crossing computation.</p>
<p>The best work I know of on segmented stacks and performance is described in the paper <a href="https://dl.acm.org/doi/10.1145/249069.231395" rel="noreferrer">&quot;Representing Control in the Presence of One-Shot Continuations&quot; by Carl Bruggeman, Oscar Waddell, and Kent Dybvig</a>.  The predecessor paper on first-class continuations is also good.  Regrettably, both papers omit a lot of detail.</p>

CC BY-SA 4.0
2023-05-19T21:39:37.867Z
2023-05-19T21:39:37.867Z
Norman Ramsey
CC BY-SA 4.0
2023-05-22T17:25:52.917Z
Thank you for the information. These are exactly the kind of papers I was looking for. Moving some stack frames to the new segment seems like an interesting mitigation technique as well.

It seems that regardless, some compile time analysis and heuristics are needed to make this option viable, which is likely why programming languages moved away from this model in favor of other solutions.
WormholeX
# Segmented Stack Efficiency
Posted by: username_0 on 2023-05-18
Segmented stacks are one method to enable the growth of execution stacks in multi-threaded paradigms at runtime, instead of having to statically pre-allocate a fixed-sized stack at compile time.
Some languages including Go and Rust at one point in their design considered using segmented stacks for their runtime concurrent stack management. However, they eventually sought other options, partially due to the problem of hot splits.
Hot splits refer to the constant allocation and deallocation of stack memory when a tight loop straddles an allocation boundary. However, it seems to me a way to mitigate the problem is to allocate stack memory as needed, but only deallocate when the stack pointer reaches the previous stack segment. As an example:
|-------| --> |-------| --> |-------|
                             ^SP    New segment just allocated    

|-------| --> |-------| --> |-------|
                     ^SP            New segment still maintained

|-------| --> |-------|
       ^SP                          New segment only now gets deallocated

While this doesn't resolve the issue of having to jump around in memory at stack boundaries, this does (at least on paper) seem to significantly mitigate the issue of hot swapping without too much extra bookkeeping. Am I missing something? What are some of the other problems with segmented stacks?
**Tags:** language-design language-comparison stack
---
## 1 answers
### Answer by username_1 on 2023-05-19. Score: 9 | Accepted answer
Even if the new segment is maintained, crossing that boundary in a tight loop can be expensive. The better solution is that when a new segment is allocated, a few frames are moved from the youngest existing segment into the new segment. Before the segment boundary can be crossed again, those frames have to finish their work. This trick is a way of introducing hysteresis into the boundary-crossing computation.

The best work I know of on segmented stacks and performance is described in the paper ["Representing Control in the Presence of One-Shot Continuations" by Carl Bruggeman, Oscar Waddell, and Kent Dybvig](https://dl.acm.org/doi/10.1145/249069.231395). The predecessor paper on first-class continuations is also good. Regrettably, both papers omit a lot of detail.
> **Comments:**
> **username_0** (2023-05-22): Thank you for the information. These are exactly the kind of papers I was looking for. Moving some stack frames to the new segment seems like an interesting mitigation technique as well.

It seems that regardless, some compile time analysis and heuristics are needed to make this option viable, which is likely why programming languages moved away from this model in favor of other solutions.  
---
