`nsAvailableMemoryWatcher::mTimer` was nullptr when `LowMemoryCallback()` tried to
initialize a timer via `OnLowMemory()`. There are two possible reasons.
The first case is that NS_NewTimer() returned nullptr because the available memory was
already low when initializing `nsAvailableMemoryWatcher`. In this case, we should not
register the callback.
The second case is the low-memory callback was queued while shutting down
`nsAvailableMemoryWatcher` (just before we unregiter the callback). We do refcount
the object and use the mutex correctly, but we touch the nulled out member. We should
make an early return if the object was shut down.
Differential Revision: https://phabricator.services.mozilla.com/D118745
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
This particular race is a tricky one - there's no perfect solution to protecting the timer thread from being called in `cancel` while being dereferenced. This ensures that we won't run into that problem by locking all of our TimerThread calls behind a mutex inside a wrapper class. Then we hold onto the wrapper class until after we shutdown `nsThreadManager`, in which case no background thread pools should be active anymore to call `nsTimerImpl::Cancel`.
For reference, the worst-case scenario happens when another thread dereferences `gThread` [between these two calls](https://searchfox.org/mozilla-central/rev/98a9257ca2847fad9a19631ac76199474516b31e/xpcom/threads/nsTimerImpl.cpp#402-403), in which case we will get stuck on a dereferenced mutex. By putting the check and the actual call into `gThread` behind a mutex maybe we can prevent this issue.
Differential Revision: https://phabricator.services.mozilla.com/D115453
The "magic static" objects created in `nsThread::ThreadList` and
`nsThread::ThreadListMutex` have non-trivial destructors, so they end up
setting `atexit` hooks.
I'd like to switch these over to be `StaticLocalAutoPtr`s which were added
specifically for the purpose of holding magic statics, and have trivial
destructors.
Differential Revision: https://phabricator.services.mozilla.com/D117549
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
ATK, Windows and XPCOM expect aria attribute keys to be stripped of
their aria- prefix. We should still store the item using the aria_ atom
and then strip the prefix when converting the key to a string.
Differential Revision: https://phabricator.services.mozilla.com/D116786
Before this patch, we use InputPriorityController::DidRunTask to change
InputVsyncState which is problematic.
Consider this scenario
1. Two events are in the queue, vsync(V1) and input(I1)
2. I1 runs and starts an inner event loop (We only expect one input
event to be run because there's only one input event)
3. Another input event(I2) arrives
4. Inner event loop picks I2 to run
5. When I2 is finished, it sets the InputVsyncState to `RunVsync`
6. I1's DidRunTask is called and crashed because the state shouldn't
be `RunVsync`.
This patch moves the code which checks InputVsyncState from `DidRunTask`
to `WillRunTask` so that the state is correctly checked and updated
before the input task is about to run.
Differential Revision: https://phabricator.services.mozilla.com/D117336
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
Bug 1711610 moved `AvailableMemoryTracker::Init()` from `NS_InitXPCOM` to `XRE_mainRun`,
but it caused memory degradation because `AvailableMemoryTracker` was no longer initialized
in the child processes.
I made that part for `nsAvailableMemoryWatcher` to cache the pref value in the earlier design,
but it's not needed at all in the current design because `nsAvailableMemoryWatcher` loads
a mirror value every time.
This patch reverts `AvailableMemoryTracker::Init()` back to `NS_InitXPCOM`.
Differential Revision: https://phabricator.services.mozilla.com/D116742
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
Jeff Muizelaar
Florian Quèze
Toshihito Kikuchi
Jon Coppeard
Nika Layzell
Alexandru Michis
Kris Maglione
Butkovits Atila
R Aravind
Andrew Osmond
Brindusan Cristian
kriswright
Iulian Moraru
Sean Feng
Aaron Klotz
Mats Palmgren
Gabriele Svelto
Michelle Goossens
Eitan Isaacson
Dorel Luca
Andrey Bienkowski
Doug Thayer
Csoregi Natalia
Emilio Cobos Álvarez
Sandor Molnar