Subscribe to memory pressure events on macOS and add crash report annotations to parent and content process crash reports that can be used to determine if the system was under memory pressure at the time of the crash.
Include the memory pressure level reported via the DISPATCH_SOURCE_TYPE_MEMORYPRESSURE dispatch with timestamps of transitions, the memory pressure level as read from the kern.memorystatus_vm_pressure_level sysctl, and a measurement of the percentage of available memory in the system read from the kern.memorystatus_level sysctl.
Differential Revision: https://phabricator.services.mozilla.com/D116725
Add initial support for the color-scheme CSS property, allowing pages to
choose between light and dark system colors per-element, and such.
Things that are left to do so that this can be enabled by default:
* Dark system colors on Windows / Android / Standins.
* Dark Canvas/CanvasText/Link visited colors (which right now are set
via PreferenceSheet).
* Dark form controls in nsNativeBasicTheme.
* Processing the color-scheme meta tag to fill-in
Document::mColorSchemeBits.
But this seems like enough progress to be landable on its own.
Differential Revision: https://phabricator.services.mozilla.com/D120843
Subscribe to memory pressure events on macOS and add crash report annotations to parent and content process crash reports that can be used to determine if the system was under memory pressure at the time of the crash.
Include the memory pressure level reported via the DISPATCH_SOURCE_TYPE_MEMORYPRESSURE dispatch with timestamps of transitions, the memory pressure level as read from the kern.memorystatus_vm_pressure_level sysctl, and a measurement of the percentage of available memory in the system read from the kern.memorystatus_level sysctl.
Differential Revision: https://phabricator.services.mozilla.com/D116725
The new event is recoreded when we detect the system's memory is no longer low.
Each event object contains three numbers:
1) how many times a tab was unloaded during the low-memory situation
2) how many memory-pressure events were dispatched during the low-memory
situation
3) how long we were in the low-memory situation in seconds
These need to be collected as the event ping because the memory situation
may repeatedly be switched between low-memory and high-memory. We want to
collect it every time the memory situation gets back to normal. If we collect
it as the main ping (like Histogram), all numbers are summed up and we cannot
evaluate each low-memory period.
Differential Revision: https://phabricator.services.mozilla.com/D120021
When the physical memory is low, Windows OS triggers the memory notification callback,
but we don't take any action if the commit space is not low because it is not the case
of a potential OOM crash. The problem is in that case, we unregister the wait handle
and exit from the callback. This means we lose a way to watch memory after that.
The proposed fix is to start a timer before exiting the callback. We could re-register
the callback, but it could be triggered too quickly if the low-physical-but-high-commit-space
situation lasts long. After the timer starts, the first timer handler (interval: 10 sec)
checks the commit space again, and if the commit space is still not low at that time,
we re-register the callback and stop the timer.
One tricky situation we need to consider is we don't actually start the timer while
the user is inactive. In that case, we mark the flag `mNeedToRestartTimerOnUserInteracting`
and start the timer when the user becomes active later. With that, `OnHighMemory` can
be executed even when we didn't in the low-memory situation. So we need to check another
flag `mUnderMemoryPressure` and record the telemetry and send a memory-pressure-stop event
only when we were in the low-memory situation.
Differential Revision: https://phabricator.services.mozilla.com/D120022
I'm not sure what information would be useful in other OSes, so ifdef
the row for GTK for now, but I made this trivial to show in Windows /
macOS / Android as soon as they return useful information.
Differential Revision: https://phabricator.services.mozilla.com/D120331
After looking through the methods which have this assertion, I couldn't
find any examples of places where not having a specific "link thread"
sequence would cause any issues. I think these assertions can and should
be removed.
The main change required by this was to remove the `!NS_IsMainThread()`
assertion from the SchedulerGroup listener. Due to how callbacks work,
it would be possible for a vsync message to be detected by a
MessageChannel from the main thread if it was sent before the channel
was bound. I don't believe that this change should cause any issues.
Differential Revision: https://phabricator.services.mozilla.com/D119348
This is a step towards removing object private slots.
Classes with JSCLASS_PRIVATE_IS_NSISUPPORTS now use JSCLASS_SLOT0_IS_NSISUPPORTS
instead. For most classes this means we need to add an extra reserved slot and remove
the private slot.
Global objects (SimpleGlobalObject and the XPConnect BackstagePass and Sandbox globals)
however can use the JSCLASS_GLOBAL_APPLICATION_SLOTS already there. These slots were
only used for WebIDL DOM globals until now.
Differential Revision: https://phabricator.services.mozilla.com/D119502
This is the main part to address bug 1701368.
Before this patch, `nsAvailableMemoryWatcher` directly broadcasted a memory-pressure
event when we enter into a low-memory situation and `TabUnloader` unloaded a tab in
response to the memory-pressure message. We want to decouple `TabUnloader` from
memory-pressure listeners because unloading a tab may solve a low-memory situation
alone.
With this patch, if `nsAvailableMemoryWatcher` detects a low-memory situation,
it invokes `TabUnloader` synchronously via an XPCOM interface. If `TabUnloader`
unloads a tab, we don't do any further action. If there is no discardable tab,
`TabUnloader` notifies back `nsAvailableMemoryWatcher` via another XPCOM interface,
so that `nsAvailableMemoryWatcher` can notify of a memory-pressure event.
Differential Revision: https://phabricator.services.mozilla.com/D117673
This patch introduces an XPCOM object which is represented by the single instance of
`nsAvailableMemoryWatcherBase` so that `nsAvailableMemoryWatcher` can synchronously
access `TabUnloader`.
We currently implement a watcher class for Windows only. For other platforms, what
we need to do is to define a class inherinting `nsAvailableMemoryWatcherBase` and
a simple factory method `CreateAvailableMemoryWatcher()` returning an instance of
that class.
Differential Revision: https://phabricator.services.mozilla.com/D118393
This patch removes dependency on the available physical memory.
With this patch, `nsAvailableMemoryWatcher` triggers `OnLowMemory` when the available
commit space is low, and triggers `OnHighMemory` when the available commit space is
no longer low.
The key part of this change is the `if` block in `nsAvailableMemoryWatcher::Notify`,
where we use a single condition `IsCommitSpaceLow()` to declare either Low or High.
After this change, `OnLowMemory` is called not only in the main thread but also in
a worker thread. So `StartPollingIfUserInteracting` also needs a lock to protect
`mPolling`.
Differential Revision: https://phabricator.services.mozilla.com/D117672
We had `NS_DispatchMemoryPressure` and `NS_DispatchEventualMemoryPressure`
to dispatch a memory-pressure event which took `MemPressure_New` and
`MemPressure_Ongoing` to translate into "low-memory" and "low-memory-ongoing"
message respectively.
With that model, we could end up sending a wrong message if somebody
called the API with `MemPressure_Ongoing` without sending `MemPressure_New`.
To avoid that, this patch removes `MemPressure_Ongoing` and makes
the API decide whether it should dispatch a "new" event or "ongoing" event.
Differential Revision: https://phabricator.services.mozilla.com/D119122
1. Use `nsAutoHandle` instead of a raw `HANDLE`
2. Add a dtor with `MOZ_ASSERT`
3. Prevent double init
4. Cache `nsAvailableMemoryWatcher::mObserverSvc`
Differential Revision: https://phabricator.services.mozilla.com/D117670
This patch splits `nsAvailableMemoryWatcher` into 1) an nsISupports-derived class
`nsAvailableMemoryWatcherBase` and 2) a platform-specific class `nsAvailableMemoryWatcher`,
taking out the 2) part as a new file AvailableMemoryWatcherWin.cpp without any change.
Test cases for `nsAvailableMemoryWatcher` will be added by a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D117669
This is the main part to address bug 1701368.
Before this patch, `nsAvailableMemoryWatcher` directly broadcasted a memory-pressure
event when we enter into a low-memory situation and `TabUnloader` unloaded a tab in
response to the memory-pressure message. We want to decouple `TabUnloader` from
memory-pressure listeners because unloading a tab may solve a low-memory situation
alone.
With this patch, if `nsAvailableMemoryWatcher` detects a low-memory situation,
it invokes `TabUnloader` synchronously via an XPCOM interface. If `TabUnloader`
unloads a tab, we don't do any further action. If there is no discardable tab,
`TabUnloader` notifies back `nsAvailableMemoryWatcher` via another XPCOM interface,
so that `nsAvailableMemoryWatcher` can notify of a memory-pressure event.
Differential Revision: https://phabricator.services.mozilla.com/D117673
This patch introduces an XPCOM object which is represented by the single instance of
`nsAvailableMemoryWatcherBase` so that `nsAvailableMemoryWatcher` can synchronously
access `TabUnloader`.
We currently implement a watcher class for Windows only. For other platforms, what
we need to do is to define a class inherinting `nsAvailableMemoryWatcherBase` and
a simple factory method `CreateAvailableMemoryWatcher()` returning an instance of
that class.
Differential Revision: https://phabricator.services.mozilla.com/D118393
This patch removes dependency on the available physical memory.
With this patch, `nsAvailableMemoryWatcher` triggers `OnLowMemory` when the available
commit space is low, and triggers `OnHighMemory` when the available commit space is
no longer low.
The key part of this change is the `if` block in `nsAvailableMemoryWatcher::Notify`,
where we use a single condition `IsCommitSpaceLow()` to declare either Low or High.
After this change, `OnLowMemory` is called not only in the main thread but also in
a worker thread. So `StartPollingIfUserInteracting` also needs a lock to protect
`mPolling`.
Differential Revision: https://phabricator.services.mozilla.com/D117672
We had `NS_DispatchMemoryPressure` and `NS_DispatchEventualMemoryPressure`
to dispatch a memory-pressure event which took `MemPressure_New` and
`MemPressure_Ongoing` to translate into "low-memory" and "low-memory-ongoing"
message respectively.
With that model, we could end up sending a wrong message if somebody
called the API with `MemPressure_Ongoing` without sending `MemPressure_New`.
To avoid that, this patch removes `MemPressure_Ongoing` and makes
the API decide whether it should dispatch a "new" event or "ongoing" event.
Differential Revision: https://phabricator.services.mozilla.com/D119122
1. Use `nsAutoHandle` instead of a raw `HANDLE`
2. Add a dtor with `MOZ_ASSERT`
3. Prevent double init
4. Cache `nsAvailableMemoryWatcher::mObserverSvc`
Differential Revision: https://phabricator.services.mozilla.com/D117670
This patch splits `nsAvailableMemoryWatcher` into 1) an nsISupports-derived class
`nsAvailableMemoryWatcherBase` and 2) a platform-specific class `nsAvailableMemoryWatcher`,
taking out the 2) part as a new file AvailableMemoryWatcherWin.cpp without any change.
Test cases for `nsAvailableMemoryWatcher` will be added by a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D117669
`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
Bas Schouten
Zibi Braniecki
Nika Layzell
Butkovits Atila
Cosmin Sabou
Molly Howell
Sandor Molnar
Haik Aftandilian
Emilio Cobos Álvarez
Iulian Moraru
Toshihito Kikuchi
Gijs Kruitbosch
Florian Quèze
Tom Ritter
Tooru Fujisawa
Jan de Mooij
Paul Bone
Alexandru Michis
Adam Gashlin
Mozilla Releng Treescript
Jeff Muizelaar
Jon Coppeard