Re: Split Stacks proposal

[Mathieu Lacage <mathieu dot lacage at sophia dot inria dot fr>]

comments below,

On Thu, 2009-02-26 at 14:05 -0800, Ian Lance Taylor wrote:
> 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.

It would be totally awesome to do this if you could provide an option to
delegate to a user-provided function the allocation and deallocation of
the stack blobs needed by threads.

i.e., the problem I run into is that I create a lot of user-space
threads and I need to allocate at the very least 2 pages (1 normal page,
1 guard page) for each thread:
  - 2 pages of address space is a lot if you have a lot of threads: it's
easy to run out of address space (physical memory is less of a concern
for me)
  - 2 pages is not enough for a lot of threads and if one of my threads
hits the 2-page limit, I have to stop my program and restart it with a
bigger stack space for the offending thread which can be quickly
"annoying".

So, ideally, I would be able to not allocate statically any address
space for my threads and defer stack space allocation only when needed.
Ideally, I would even be able to use heap memory for that stack space if
I wanted to.

Another use-case I could foresee for this would be to be able to profile
the runtime stack-usage of an application/set of threads to optimize it.

> I would be interested in hearing comments about this.
> 
> I'm not currently working on this, but I may start working on it at some
> point.

I looked a bit at the page you pointed. A couple of questions:

  - if you want to use the stack protector and split stacks, it should
be fairly trivial to extend the data structure which contains the stack
protector with a new field, no ?

  - what would be a typical size for the stack space slop ? (for
example, on i386 ?)

  - I understand that you need to copy the function parameters from the
old stack to the new stack, but, why would you need to invoke the C++
copy or move constructors for this ? Would a memcpy not be sufficient to
ensure proper C++ semantics in this case ? An example which shows how a
memcpy would break might be interesting.

Mathieu