On Thu, Jan 30, 2014 at 6:33 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> On Thu, Jan 30, 2014 at 12:27 PM, Matthieu Monrocq > <matthieu.monr...@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. >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
