Comment 13 for bug 1757517

(In reply to comment #7)
> I can provide some information about Chrome built with -fprofile-generate:
>
> p __static_tls_size
> $1 = 114880
>
> Now let's look at how Chrome allocates thread stacks:
>
> http://code.google.com/p/chromium/source/search?q=kShutdownDetectorThreadStackSize&origq=kShutdownDetectorThreadStackSize&btnG=Search+Trunk
>
> http://code.google.com/p/chromium/source/search?q=kWorkerThreadStackSize&origq=kWorkerThreadStackSize&btnG=Search+Trunk
>
> are two examples. There are other stack sizes too. From what I have seen, if
> the stack size is less than __static_tls_size, it just fails to allocate the
> stack. If it is something like 128k, it gets allocated, but soon runs out of
> stack into the guard page where it causes a segfault on a random function (as
> it allocating locals for the function).

That's brutal. You have a 128k stack with 114k of thread local data, a guard page, the thread descriptor, and you've barely got anything left.

Thank you for some real-world data, that helps put things into perspective.