[rust-dev] What of semi-automated segmented stacks ?

Daniel Micay danielmicay at gmail.com
Thu Jan 30 09:33:25 PST 2014


On Thu, Jan 30, 2014 at 12:27 PM, Matthieu Monrocq
<matthieu.monrocq at gmail.com> wrote:
> Hello,
>
> Segmented stacks were ditched because of performance issues that were never
> fully resolved, especially when every opaque call (C, ...) required
> allocated a large stack up-front.
>
> Still, there are platforms (FreeBSD) with small stacks where the idea of
> segmented tasks could ease development... so what if we let the developer
> ship in ?

Rust can and does choose the stack size itself. This can exposed as an
API feature too.

> The idea of semi-automated segmented stacks would be:
>
> - to expose to the user how many bytes worth of stack are remaining
>
> - to let the user trigger a stack switch
>
>
> This system should keep the penalty close to null for those who do not care,
> and be relatively orthogonal to the rest of the implementation:

If Rust isn't going to be using the segmented stack prelude (1-5%
performance hit), it needs guard pages. This means the smallest stack
segment size you can have with a "free" solution is 8K. It will
consume less virtual memory than a fixed-size stack, but not more
physical memory.

> - how many bytes remaining carries little to no penalty: just a pointed
> substraction between the current stack pointer and the "end-of-stack"
> pointer (which can be set once and for all at thread start-up)
>
> - the stack switch is voluntary, and can include a prelude on the new stack
> that automatically comes back to its parent so that most code should not
> care, no penalty in regular execution (without it)
>
> - I foresee some potential implementation difficulty for the unwinder, did
> it ever work on segmented stacks ? Was it difficult/slow ? Does performance
> of unwind matter that much ?

Unwind performance doesn't matter, and is already really slow by design.


More information about the Rust-dev mailing list