This seems like it will be useful to help figure out what is being
created/destroyed at inappropriate times, and identify potential
problems faster.
Differential Revision: https://phabricator.services.mozilla.com/D136944
Adds a crash annotation, `LinuxUnderMemoryPressure`, which the memory pressure monitor updates based on whether or not it is under memory pressure.
Differential Revision: https://phabricator.services.mozilla.com/D133555
Calling NSS_IsInitialized() off the main thread caused intermittent tsan failures because NSS_IsInitialized() reads global variable nssIsInitted without acquiring the nssInitLock lock.
During Firefox startup, about 1000 nsIDs are generated, but only about 10 are generated off the main thread, so this change has very little impact on how often nsID::GenerateUUID() will use NSS's RNG. Of the nsIDs generated on the main thread during startup, about 600 are generated before NSS is initialized (so they use MFBT's RNG) and 400 are generated after NSS is initialized.
After Firefox reaches a steady state, loading a light web page like google.com generates about 300 nsIDs and a heavy web page like cnn.com generates about 2000 nsIDs. All these nsIDs are generated on the main thread using NSS's RNG.
Differential Revision: https://phabricator.services.mozilla.com/D134233
Calling NSS_IsInitialized() off the main thread caused intermittent tsan failures because NSS_IsInitialized() reads global variable nssIsInitted without acquiring the nssInitLock lock.
During Firefox startup, about 1000 nsIDs are generated, but only about 10 are generated off the main thread, so this change has very little impact on how often nsID::GenerateUUID() will use NSS's RNG. Of the nsIDs generated on the main thread during startup, about 600 are generated before NSS is initialized (so they use MFBT's RNG) and 400 are generated after NSS is initialized.
After Firefox reaches a steady state, loading a light web page like google.com generates about 300 nsIDs and a heavy web page like cnn.com generates about 2000 nsIDs. All these nsIDs are generated on the main thread using NSS's RNG.
Differential Revision: https://phabricator.services.mozilla.com/D134233
This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
Historically, va_copy was not supported everywhere (notably, MSVC didn't
have it). That's not true anymore. We already have code such as
xpcom/base/Logging.cpp that uses it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D133458
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
This stops destructing the stencils held by ScriptPreloader on release build,
to avoid the shutdown hang caused by thrashing.
Also:
* Move ScriptPreloader::Cleanup from xpcom-shutdown notification to ScriptPreloader destructor, given there's no reason for having 2 steps
* Replace ClearOnShutdown call with explicit function call for the singleton deletion, for simplicity
* Remove now-unused PostJSShutDown phase
Differential Revision: https://phabricator.services.mozilla.com/D130839
Alexandre Lissy
Cristian Tuns
Nika Layzell
kriswright
Chris Peterson
Iulian Moraru
Bobby Holley
Mike Hommey
Sandor Molnar
Anny Gakhokidze
Peter Van der Beken
Norisz Fay
Alexandre Poirot
shravanrn@gmail.com
Butkovits Atila
Jon Coppeard
Noemi Erli
Csoregi Natalia
Narcis Beleuzu
Steve Fink
Jens Stutte
Deian Stefan
Ben Hearsum
Tooru Fujisawa