This replaces TaskController::mThreadPoolCV with an individual condition
variable for each thread, and uses these to wake individual threads. The task
for each thread is assigned beforehand by setting mCurrentTask.
The counter mIdleThreadCount is used to quickly tell if there are any threads
free.
This splits TaskController::RunPoolThread to move the task selection part to
SelectTaskToRun. MaybeDispatchOneTask is called whenever there may be a new
task to dispatch (this runs from both the main thread and pool threads).
I tried to keep the same behaviour with mEffectiveTaskPriority but I don't
fully understand what this is being used for.
Differential Revision: https://phabricator.services.mozilla.com/D214958
This passes a pointer to the current pool thread to RunPoolThread, removing the
need for thread local storage. It also does some refactoring, moving the
PoolThread definition out of the header file.
This also changes the thread vector to use UniquePtr is necessary for the next
patch which adds a CondVar to PoolThread.
Differential Revision: https://phabricator.services.mozilla.com/D214957
Using a static std::unique_ptr introduces atexit destructors which can
cause the thread pool to exit in a non-clean state.
Use StaticAutoPtr to avoid this. Clean-up a bit while at it.
We could move the thread-joining into the TaskController destructor too,
that might be worth doing.
Differential Revision: https://phabricator.services.mozilla.com/D190552
ASan builds use more stack space so need a larger stack size. Note that this matches
what we already do for the JS overrecursion limit for the main thread.
This fixes overrecursion errors from the parser when parsing JS files off-thread
on YouTube.
Differential Revision: https://phabricator.services.mozilla.com/D135201
Threads are implicitly members of the multi-threaded apartment and calls to
CoInitializeEx (and CoUninitializeEx) cause user32 to load.
Differential Revision: https://phabricator.services.mozilla.com/D124933
Threads are implicitly members of the multi-threaded apartment and calls to
CoInitializeEx (and CoUninitializeEx) cause user32 to load.
Differential Revision: https://phabricator.services.mozilla.com/D124933
With the new ThreadRegistration classes, it becomes more important to properly balance registrations with unregistrations. Though mismatches are safely handled when they happen, in particular missing unregistrations can lead to leaks that make tests fail.
This patch changes `PROFILER_REGISTER_THREAD` in TaskController.cpp to `AUTO_PROFILER_REGISTER_THREAD`, to ensure that TaskController threads get unregistered when they're finished.
In AsyncLogger.h, a pair of `PROFILER_REGISTER_THREAD` and `PROFILER_UNREGISTER_THREAD` is converted to a single `AUTO_PROFILER_REGISTER_THREAD`. This is equivalent, but the latter is safer, in case the code in-between later changes to include early breaks or returns.
Differential Revision: https://phabricator.services.mozilla.com/D123228
Currently the XPCOM thead pool creates one less thread than the number of
cores. The JS helper thread pool creates an equal number.
I tested increasing the number of threads to match the number of cores and
found it resolved this regression.
Differential Revision: https://phabricator.services.mozilla.com/D118327
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
This adds plumbing to make the JS engine set the stack quota based on the
actual stack size for external thread pool threads (and internal thread pool
ones).
The quota is calculated as 90% of the size, which is currently hardcoded into
the constants.
Differential Revision: https://phabricator.services.mozilla.com/D118183
Currently parallel Wasm compilation requires at least two threads for
architectural reasons. This patch updates the TaskController thread policy such
that there are always two threads available, even on single core systems.
Differential Revision: https://phabricator.services.mozilla.com/D117002
The JS helper thread system needs to know how many threads are available, in
particular because parallel Wasm compilation needs at least two threads to
avoid deadlock. This adds a method to get the count from TaskController and
passes it through to the JS engine when setting up the thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D116220
Jon Coppeard