core.thread.Fiber --- runtime stack overflow unlike goroutines

[Martin Nowak via Digitalmars-d-learn]

On 08/15/2014 05:09 PM, Sean Kelly wrote:
> At least on OSX, it appears that mapping memory is constant time
> regardless of size, but there is some max total memory I'm allowed to
> map, presumably based on the size of a vmm lookup tabe.  The max block
> size I can allocate is 1 GB, and I can allocate roughly 131,000 of these
> blocks before getting an out of memory error.  If I reduce the block
> size to 4 MB I can allocate more than 10M blocks without error.  I think
> some default stack size around 4 MB seems about right.  Increasing the
> size to 16 MB failed after about 800,000 allocations, which isn't enough
> (potential) fibers.

While pages are committed lazily it's not free to map more memory.
For example the kernel will have to allocate and setup more page table 
entries.
Furthermore we might need to use MAP_NORESERVE to not run into 
overcommit limitations, but that's not available on all OSes I think.

It might make sense to raise the stack size again [1] if we had an idea 
what size would avoid common issues (vibe.d uses 64kB). 4MB is too much 
for the default size IMO.

Given that the stack size is configurable let's instead try to improve 
the diagnostic of Fiber stack overflows first, we should also map a 
guard page on posix and add a segfault handler to detect overflows.

[1]: 
https://github.com/D-Programming-Language/druntime/commit/9dca50fe65402fb3cdfbb689f1aca58dc835dce4#diff-8bb12ed976acf0a5132e877ec5a01ea8R3163