On 2/2/13 4:50 AM, Michael Neumann wrote:
Ultimately we never often want a stack to be increased in size as this seems to be a quite expensive operation. Calling a function that crosses stack space boundaries (i.e. when it has to alloc new stack space) inside a loop might severly affect performance. "do reserve_stack" could be used to prevent that, but the programmer need to be aware of that. At least theoretical it should be possible to calculate how much stack space a given function needs including all the space that all called functions need. Recursive functions would result in "unlimited stack space", just because we cannot analyse the depths of the calls. But for most of the code, we would know the maximum stack space used. We could use this when we start new tasks to allocate a contiguous stack large enough to hold the whole computation of that task without the need to resize (in which case we could optimize away the checks in front of each function).
You have a good point here, and this is a use case I hadn't considered. It's often desirable to have a task allocate a large amount of stack up front and use it for all FFI calls: in fact, this corresponds directly to the JavaScript task in Servo. In some sense this is a generalization of the use case I posted earlier, in which multiple FFI calls would be grouped under the same `reserve_stack` call.
So I suppose `reserve_stack` would simply check to see whether there's enough stack space at runtime and turn into a no-op if there is. The safe interfaces to functions would always use `reserve_stack`. (We would enforce this with a lint pass, as earlier.) Thus, in general, if you see `__morestack` high in your profiles, you can fix the thrashing by simply adding a call to `reserve_stack` high in the call chain.
This all sounds very attractive to me now. Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
