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
