Switching to the C stack is slow

[brson]

pcwalton saw the C-stack-switching __morestack function show up surprisingly high on profiles. All this function does is change sp and call a function by pointer. Probably this is very bad for branch prediction.

[brson]

Branch prediction is the reason the stack-growth __morestack function has such a bizarre structure.

[brson]

Possibly we can just use the stack-growth __morestack function to do stack switching as well by setting the stack boundary to a value that is guaranteed to trip the call to __morestack and setting a flag in the task structure to put it into a different 'mode'. This would make branch prediction work and eliminate the need to marshall arguments through a struct on the stack.

[brson]

We tried using __morestack for this and it had too much overhead from other stack growth code to make it worthwhile.

[emberian]

Visiting for triage; still relevant.

[huonw]

Triage: #8535 changed (some of) the way extern fns work, so I have no idea if this is valid, and I can't create a testcase that reproduces it (possibly because segmented stacks are disabled in the new rt?).

@nikomatsakis would your changes have affected this?

[nikomatsakis]

@huonw yes and no. We no longer use the old C stack switching mechanism, we only use the "stack-growth" variant of __morestack. Moreover, users can now move the stack switch so it occurs earlier, which helps to eliminate overhead. However, the mechanism itself is still probably too slow -- though whether it can be further optimized is unclear, @pcwalton thought no. Certainly we can't eliminate the megamorphic call site that Brian referred to.

[catamorphism]

Obsolete