[rust-dev] What of semi-automated segmented stacks ?
matthieu.monrocq at gmail.com
Thu Jan 30 09:27:27 PST 2014
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 ?
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:
- 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 ?
In the absence of segmented stacks, the user can only resolve to using
another task to get a "free" stack. Unfortunately, because of the (great!)
memory safety of Rust this other task cannot readily access its parent
I do not remember whether this idea was investigated when segmented tasks
were removed. I thought it might be interesting to consider, although... it
is probably useless for 1.0 anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev