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

Matthieu Monrocq 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
task's memory.

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.

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140130/5707d16e/attachment.html>

More information about the Rust-dev mailing list