Stack allocation for C++ green threads

 

I'm doing some research in C++ green threads, mostly boost::coroutine2 and similar POSIX functions like makecontext()/swapcontext() , and planning to implement a C++ green thread library on top of boost::coroutine2 . Both require the user code to allocate a stack for every new function/coroutine.

My target platform is x64/Linux. I want my green thread library to be suitable for general use, so the stacks should expand as required (a reasonable upper limit is fine, eg 10MB), it would be great if the stacks could shrink when too much memory is unused (not required). I haven't figured out an appropriate algorithm to allocate stacks.

After some googling, I figured out a few options myself:

  • use split stack implemented by the compiler (gcc -fsplit-stack), but split stack has performance overhead. Go has already moved away from split stack due to performance reasons.
  • allocate a large chunk of memory with mmap() hope the kernel is smart enough to leave the physical memory unallocated and allocate only when the stacks are accessed. In this case, we are at the mercy of the kernel.
  • reserve a large memory space with mmap(PROT_NONE) and setup a SIGSEGV signal handler. In the signal handler, when the SIGSEGV is caused by stack access (the accessed memory is inside the large memory space reserved), allocate needed memory with mmap(PROT_READ | PROT_WRITE) . Here is the problem for this approach: mmap() isn't asynchronous safe, cannot be called inside a signal handler. It still can be implemented, very tricky though: create another thread during program startup for memory allocation, and use pipe() + read()/write() to send memory allocation information from the signal handler to the thread.

    • A few more questions about option 3:

  • I'm not sure the performance overhead of this approach, how well/bad the kernel/CPU performs when the memory space is extremely fragmented due to thousands of mmap() call ?
  • Is this approach correct if the unallocated memory is accessed in kernel space ? eg when read() is called ?

    • Are there any other (better) options for stack allocation for green threads ? How are green thread stacks allocated in other implementations, eg Go/Java ?

    The way that glibc allocates stacks for normal C programs is to mmap a region with the following mmap flag designed just for this purpose: 

       MAP_GROWSDOWN
          Used for stacks.  Indicates to the kernel virtual memory  system
          that the mapping should extend downward in memory.

    For compatibility, you should probably use MAP_STACK too. Then you don't have to write the SIGSEGV handler yourself, and the stack grows automatically. The bounds can be set as described here What does "ulimit -s unlimited" do?

    If you want a bounded stack size, which is normally what people do for signal handlers if they want to call sigaltstack(2) , just issue an ordinary mmap call.

    The Linux kernel always maps physical pages that back virtual pages, catching the page fault when a page is first accessed (perhaps not in real-time kernels but certainly in all other configurations). You can use the /proc/<pid>/pagemap interface (or this tool I wrote https://github.com/dwks/pagemap) to verify this if you are interested.

    Why mmap? When you allocate with new (or malloc) the memory is untouched and definitely not mapped. 

    const int STACK_SIZE = 10 * 1024*1024;
char*p = new char[STACK_SIZE*numThreads];

    p now has enough memory for the threads you want. When you need the memory, start accessing p + STACK_SIZE * i

    链接地址: http://www.djcxy.com/p/53190.html

    上一篇: 我可以在LLVM中设置堆栈指针吗？

    下一篇: C ++绿色线程的堆栈分配