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
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
If IdleTaskManager is suspended and non-idle task _is_run_, nothing seems to guarantee idle tasks get run later.
Calling UpdateCachedIdleDeadline triggers child->parent->child ipc messages if needed and ends up enabling
IdleTaskManager.
Differential Revision: https://phabricator.services.mozilla.com/D116316
This patch introduces a new way to way to schedule input tasks, such
that input tasks remain at `InputHigh` priority normally, however, when
there's a pending `Vsync` priority task in the task queue, we
increase the priority of input tasks from `InputHigh` to `InputHighest` to
rush processing the pending input tasks.
There are two restrictions to ensure we don't delay vsync too much:
- There's a hard limit duration
- We won't process the input tasks that are newly added after we've
started to process the current number of input tasks
Differential Revision: https://phabricator.services.mozilla.com/D109499
This patch introduces a new way to way to schedule input tasks, such
that input tasks remain at `InputHigh` priority normally, however, when
there's a pending `Vsync` priority task in the task queue, we
increase the priority of input tasks from `InputHigh` to `InputHighest` to
rush processing the pending input tasks.
There are two restrictions to ensure we don't delay vsync too much:
- There's a hard limit duration
- We won't process the input tasks that are newly added after we've
started to process the current number of input tasks
Differential Revision: https://phabricator.services.mozilla.com/D109499
Noemi Erli