Rust moved away from segmented stack around 2015 because of the hot split problem. On 64-bit platforms with virtual memory, where we can map virtual pages to physical frames on demand, segmented stack has less advantage.
However, on embedded platforms, where tasks directly read from or write to physical memory, segmented stack shows significant benefits.
First, we can grow the size of the stack on demand and free the unused portion when functions return rather than allocate it statically. This improves the memory efficiency on microcontrollers whose typical RAM sizes are around 100KiB.
Second, segmented stack provides us a mechanism to prevent the stack from overflowing into other memory segments. With segmented stack, each function prologue checks the remaining free space and calls
__morestack when it is about to overflow. The runtime, which implements
__morestack, also gets a chance to gracefully kill a task if the whole system is running out of memory.
Being able to prevent stackoverflow is crucial because the safety provided by Rust's type system implicitly assumes that the underlying memory behaves obediently, but an overflowing stack easily breaks the assumption.
Embedded systems are places that often lack hardware protection, where the safety provided by the Rust language truly shines. Bringing segmentation stack back to embedded targets can resolve the loose ends.
A discussion about bringing back segmentation stack happened four years ago. Has anything changed since then? Does my argument make sense? How hard is it to implement?