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

Matthieu Monrocq matthieu.monrocq at gmail.com
Thu Jan 30 10:55:05 PST 2014

On Thu, Jan 30, 2014 at 6:33 PM, Daniel Micay <danielmicay at gmail.com> wrote:

> 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.

I think it would be a good idea, to avoid platform defaults causing
unexpected crashes. I know Clang regularly suffers on a number of tests
because of this.

Still, this seems complementary. Whilst a "large" stack to begin with is an
obvious option, there are always unfavorable cases. Today, to avoid stack
issues, I have to move from "natural" recursive style to self-managed stack
of actions and an "endless loop" so my stack is actually on the heap. It's
feasible, certainly, but it's a technical limitation getting in the way of
my intent.

And unfortunately, whilst I could allocate a 1GB stack to start with (64
bits world sure is fortunate), I have no way to foresee when I will need
such a stack and when I do not. Dynamic adaptation makes things much easier.

> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140130/ee618fb4/attachment.html>

More information about the Rust-dev mailing list