Bug 1716940 - Increase TaskController thread stack size r=bas

This increases the stack size used for task controller threads to the size
previously used for JS helper threads. Some parsing use cases can use a lot of
stack.

Differential Revision: https://phabricator.services.mozilla.com/D118184

xpcom/threads/TaskController.cpp

@@ -146,8 +146,28 @@ bool TaskController::InitializeInternal() {
   return true;
 }
 
-// Ample stack size allocated for applications like ImageLib's AV1 decoder.
-const PRUint32 sStackSize = 512u * 1024u;
+// We want our default stack size limit to be approximately 2MB, to be safe for
+// JS helper tasks that can use a lot of stack, but expect most threads to use
+// much less. On Linux, however, requesting a stack of 2MB or larger risks the
+// kernel allocating an entire 2MB huge page for it on first access, which we do
+// not want. To avoid this possibility, we subtract 2 standard VM page sizes
+// from our default.
+constexpr PRUint32 sBaseStackSize = 2048 * 1024 - 2 * 4096;
+
+// TSan enforces a minimum stack size that's just slightly larger than our
+// default helper stack size.  It does this to store blobs of TSan-specific data
+// on each thread's stack.  Unfortunately, that means that even though we'll
+// actually receive a larger stack than we requested, the effective usable space
+// of that stack is significantly less than what we expect.  To offset TSan
+// stealing our stack space from underneath us, double the default.
+//
+// Note that we don't need this for ASan/MOZ_ASAN because ASan doesn't require
+// all the thread-specific state that TSan does.
+#if defined(MOZ_TSAN)
+constexpr PRUint32 sStackSize = 2 * sBaseStackSize;
+#else
+constexpr PRUint32 sStackSize = sBaseStackSize;
+#endif
 
 void TaskController::InitializeThreadPool() {
   mPoolInitializationMutex.AssertCurrentThreadOwns();