Mathieu Lacage <mathieu.lac...@sophia.inria.fr> writes: > 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.
Yes, this would be a goal. > 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". Yes, this is the kind of issue the project is intended to address. > 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. Right. > 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. Right. >> 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 ? No, as Daniel mentioned this is part of glibc on GNU/Linux systems, and is difficult to change. > - what would be a typical size for the stack space slop ? (for > example, on i386 ?) At this point I really don't know. > - 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. Daniel showed how this can fail for objects with internal pointers. This includes __gnu_cxx::__vstring, which is likely to be the default std::string class in libstdc++ 7, so this is not an unlikely occurrence. Ian
