On Thu, Jan 30, 2014 at 12:27 PM, Matthieu Monrocq <[email protected]> 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. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
