Re: Split Stacks proposal

[Ian Lance Taylor <iant at google dot com>]

Andi Kleen <andi@firstfloor.org> writes:

> Ian Lance Taylor <iant@google.com> writes:
>
>> I've put a project proposal for split stacks on the wiki at
>> http://gcc.gnu.org/wiki/SplitStacks .  The idea is to permit the stack
>> of a single thread to be split into discontiguous segments, thus
>> permitting many more threads to be active at one time without worrying
>> about stack overflow or about wasting lots of stack space for inactive
>> threads.  The compiler would have to generate code to support detecting
>> when new stack space is needed, and to deal with some of the
>> consequences of moving to a new stack.
>
> This is mainly for 32bit systems with tight address space right? On a
> 64bit system you could just do it through the MMU by reserving enough
> free VM space for the stack in advance and then handling the page fault.

I am thinking mainly of systems with limited address space, right (if
one can call 32 bits limited).  However, it is somewhat useful even on
64-bit systems, in that you don't have to actually do all that MMU
programming, and you don't have to worry about maximal stack sizes.
That is, on a 64-bit system other approaches can be used, but this one
is simpler.


>> I would be interested in hearing comments about this.
>
> In the wiki: Possible strategies 1. 
>
> Should that be "Each function with a _large_ stack frame" ?

No.  A function with a large stack frame needs a slightly more
complicated instruction sequence to start.  It needs to incorporate the
size of the stack frame in the comparison.


> How about alloca() in your scheme?

There is a brief mention in the list of implementation steps.  alloca
and dynamic arrays will have to be implemented to check if there is
enough space on the current stack.  If there is not, they will have to
be allocated on the heap, and the space released when the function
returns.  (This is painful to do outside the compiler, but inside the
compiler it's a straightforward use of TRY_FINALLY_EXPR.)

Ian