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
Those AllocReplacement tests have been going intermittent on and off for
a while. See bug 1556754, bug 1554330, bug 1475411, bug 1544926, bug
1732998, bug 1730436.
The last non-whitespace change to the test file was bug 1433015 which
was filed for the exact same problem, but the patch didn't actually do
what it was advertizing to be doing: adding "DeathTest" to the test
names doesn't turn them into death tests.
Actually turning them into death tests doesn't fix the tests either, in
fact, it would tend to make things worse because death tests run in a
subprocess, and that subprocess runs a bunch of initialization code
including initializing threads, and all the initialization code adds
chances to race with these threads.
I'm not sure exactly why bug 1696504 makes things worse, but overall,
the problem is that these tests assume they are alone running, but they
aren't, and allocations/deallocations happening in other threads do
break the tests (IOW, the comment saying that it doesn't seem to be a
problem in practice is unfortunately wrong or outdated).
Since bug 1254779, which added these tests, things have changed, though,
and we now have another way to validate whether an allocation comes from
jemalloc or not.
Also completely disable the test when not building with jemalloc because
it's not doing anything useful (and jemalloc_ptr_info is not available
in that case).
Differential Revision: https://phabricator.services.mozilla.com/D131999
Revert some of the fix for 1722758 so that only the URL ref component is re-encoded for NSURL compatibility. Other URL fields need additional work to be addressed in a follow up.
Update the set of characters re-encoded to be as minimal as possible and include missing characters.
Add tests to ensure encoding works as expected, not just that it is accepted by NSURL.
Differential Revision: https://phabricator.services.mozilla.com/D130445
A call to InitCommandLine was added in Bug 1727180 where gArgc and gArgv are
not defined.
The same bug also re-enabled some tests that appeared to pass (but really they
were just silently crashing), this patch fixes that too.
Differential Revision: https://phabricator.services.mozilla.com/D130223
Enable tab unloading on macOS when the OS memory pressure level reaches "critical".
Add a gtest that exercises the memory pressure response by testing that a tab unload attempt occurs and the internal memory-pressure notification is sent. Test does not cause a real OS memory pressure event.
Use the memory_pressure(1) macOS command to generate artificial memory pressure events to test the browser response. For example, the following artificially puts the OS in the "critical" memory pressure level for 60 seconds.
`$ sudo memory_pressure -S -l critical -s 60`
Differential Revision: https://phabricator.services.mozilla.com/D126560
This tests that JS holders get marked gray by GC and updated when moved by
compacting GC. The latter would have caught the problem reported in bug
1731432.
Differential Revision: https://phabricator.services.mozilla.com/D127670
This tests that JS holders get marked gray by GC and updated when moved by
compacting GC. The latter would have caught the problem reported in bug
1731432.
Differential Revision: https://phabricator.services.mozilla.com/D127670
objdir/dist/include/mozilla/Queue.h:251:31: error: use of undeclared identifier 'moz_xcalloc'
xpcom/base/nsCOMPtr.h:436:5: error: static_assert failed due to requirement '1 < sizeof (TestForIID<nsIEventTarget>(nullptr))' "nsCOMPtr only works for types with IIDs. Either use RefPtr; add an IID to your type with NS_DECLARE_STATIC_IID_ACCESSOR/NS_DEFINE_STATIC_IID_ACCESSOR; or make the nsCOMPtr point to a base class with an IID."
xpcom/tests/gtest/TestDelayedRunnable.cpp:16:28: error: field has incomplete type '(anonymous namespace)::ReleaseDetector'
xpcom/tests/gtest/TestDelayedRunnable.cpp:16:3: error: 'explicit' can only appear on non-static member functions
xpcom/tests/gtest/TestDelayedRunnable.cpp:16:40: error: expected ')'
xpcom/tests/gtest/TestDelayedRunnable.cpp:16:61: error: use of undeclared identifier 'aActive'
xpcom/tests/gtest/TestDelayedRunnable.cpp:28:3: error: no template named 'Atomic'; did you mean 'mozilla::Atomic'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:34:3: error: no template named 'Atomic'; did you mean 'mozilla::Atomic'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:36:18: error: use of undeclared identifier 'TaskQueue'; did you mean 'taskQueue'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:36:18: error: variable 'taskQueue' declared with deduced type 'auto' cannot appear in its own initializer
xpcom/tests/gtest/TestDelayedRunnable.cpp:36:48: error: use of undeclared identifier 'MediaThreadType'
xpcom/tests/gtest/TestDelayedRunnable.cpp:36:48: error: use of undeclared identifier 'MediaThreadType'; did you mean 'mozilla::MediaThreadType'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:38:51: error: no matching conversion for functional-style cast from 'Atomic<bool> *' to '(anonymous namespace)::ReleaseDetector'
xpcom/tests/gtest/TestDelayedRunnable.cpp:54:3: error: no template named 'Atomic'; did you mean 'mozilla::Atomic'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:58:51: error: no matching conversion for functional-style cast from 'Atomic<bool> *' to '(anonymous namespace)::ReleaseDetector'
xpcom/tests/gtest/TestDelayedRunnable.cpp:88:3: error: use of undeclared identifier 'Unused'; did you mean 'mozilla::Unused'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:104:3: error: use of undeclared identifier 'Unused'; did you mean 'mozilla::Unused'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:109:10: error: unknown type name 'SharedThreadPool'; did you mean 'mozilla::SharedThreadPool'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:109:35: error: use of undeclared identifier 'SharedThreadPool'
xpcom/tests/gtest/TestDelayedRunnable.cpp:109:35: error: use of undeclared identifier 'SharedThreadPool'; did you mean 'mozilla::SharedThreadPool'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:110:25: error: use of function template name with no prior declaration in function call with explicit template arguments is a C++20 extension [-Werror,-Wc++20-extensions]
xpcom/tests/gtest/TestDelayedRunnable.cpp:110:36: error: unknown type name 'TaskQueue'; did you mean 'mozilla::TaskQueue'?
xpcom/tests/gtest/TestDelayedRunnable.cpp:112:36: error: unknown type name 'TaskQueue'; did you mean 'mozilla::TaskQueue'?
xpcom/tests/gtest/TestFileNTFSSpecialPaths.cpp:18:28: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFileNTFSSpecialPaths.cpp:26:28: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFileNTFSSpecialPaths.cpp:39:28: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFileNTFSSpecialPaths.cpp:279:28: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFilePreferencesWin.cpp:113:26: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFilePreferencesWin.cpp:140:26: error: use of undeclared identifier 'do_CreateInstance'
xpcom/tests/gtest/TestFilePreferencesWin.cpp:156:31: error: use of undeclared identifier 'NS_OS_TEMP_DIR'
xpcom/tests/gtest/TestJSHolderMap.cpp:50:28: error: unknown type name 'JSHolderMap'
xpcom/tests/gtest/TestJSHolderMap.cpp:52:35: error: use of undeclared identifier 'i'
xpcom/tests/gtest/TestJSHolderMap.cpp:52:45: error: use of undeclared identifier 'i'
xpcom/tests/gtest/TestJSHolderMap.cpp:52:8: error: use of undeclared identifier 'JSHolderMap'
xpcom/tests/gtest/TestJSHolderMap.cpp:52:8: error: use of undeclared identifier 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:53:24: error: use of undeclared identifier 'i'
xpcom/tests/gtest/TestJSHolderMap.cpp:54:24: error: use of undeclared identifier 'i'
xpcom/tests/gtest/TestJSHolderMap.cpp:68:3: error: unknown type name 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:73:3: error: unknown type name 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:99:3: error: unknown type name 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:104:9: error: use of undeclared identifier 'JSHolderMap'
xpcom/tests/gtest/TestJSHolderMap.cpp:104:9: error: use of undeclared identifier 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:125:41: error: use of undeclared identifier 'MakeUnique'
xpcom/tests/gtest/TestJSHolderMap.cpp:147:3: error: unknown type name 'JSHolderMap'; did you mean 'mozilla::JSHolderMap'?
xpcom/tests/gtest/TestJSHolderMap.cpp:151:41: error: use of undeclared identifier 'MakeUnique'
xpcom/tests/gtest/TestRWLock.cpp:92:3: error: no template named 'Maybe'; did you mean 'mozilla::Maybe'?
xpcom/tests/gtest/TestRWLock.cpp:95:23: error: use of undeclared identifier 'SyncRunnable'; did you mean 'mozilla::SyncRunnable'?
xpcom/tests/gtest/TestRWLock.cpp:103:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:107:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:111:7: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:120:7: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:130:5: error: unknown type name 'AutoWriteLock'; did you mean 'mozilla::AutoWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:133:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:137:7: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:142:3: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:146:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:155:5: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:159:5: error: unknown type name 'AutoTryReadLock'; did you mean 'mozilla::AutoTryReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:163:7: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:172:7: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:182:5: error: unknown type name 'AutoReadLock'; did you mean 'mozilla::AutoReadLock'?
xpcom/tests/gtest/TestRWLock.cpp:184:5: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:188:7: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:194:5: error: unknown type name 'AutoWriteLock'; did you mean 'mozilla::AutoWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:197:5: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
xpcom/tests/gtest/TestRWLock.cpp:201:7: error: unknown type name 'AutoTryWriteLock'; did you mean 'mozilla::AutoTryWriteLock'?
Differential Revision: https://phabricator.services.mozilla.com/D127042
xpcom/tests/gtest/TestAvailableMemoryWatcherWin.cpp(130,22): error: variable 'x' set but not used [-Werror,-Wunused-but-set-variable]
volatile uint8_t x = 0;
^
xpcom/tests/gtest/TestAvailableMemoryWatcherWin.cpp(152,12): error: variable 'consumed' set but not used [-Werror,-Wunused-but-set-variable]
size_t consumed = 0;
^
xpcom/tests/gtest/TestSTLWrappers.cpp:48:7: error: variable 'rv' set but not used [-Werror,-Wunused-but-set-variable]
int rv = 1;
^
Differential Revision: https://phabricator.services.mozilla.com/D126462
When adding new gtests I came across this build failure:
```
0:12.59 In file included from Unified_cpp_xpcom_tests_gtest2.cpp:2:
0:12.59 /home/kriswright/src/mozilla-unified/xpcom/tests/gtest/TestMultiplexInputStream.cpp:349:45: error: no viable conversion from 'nsCOMPtr<nsIThread>' to 'nsIEventTarget *'
```
It looks like this file needs to include nsIThread in its #includes.
Differential Revision: https://phabricator.services.mozilla.com/D125851
The goal here is to ensure we can always rely on `AppShutdown::GetShutdownPhase` to be in sync with the "real" application status, mainly this was needed for xpcshell tests to not break if we add assertions on our shutdown state on some global singletons.
We keep the existing observer notification topics but force them (on the parent process) to be issued through the new `advanceShutdownPhase` function of the startup service using the `ShutdownPhase` enum. This way we can synchronize `AppShutdown`'s internal status accordingly.
Some further notes:
# The `MOZ_ASSERT(AppShutdown::IsNoOrLegalShutdownTopic(aTopic));` in `NotifyObservers` helped a lot to identify missing cases. I think we should keep it in order to stay safe.
# Introducing the `cenum IDLShutdownPhase` helps to keep the knowledge about the mapping from shutdown phases to observer topics exclusively inside AppShutdown.cpp. Still callers must know what they do in order to choose a proper phase, of course.
# However we must be aware that `AppShutdown` this way can be kept in sync with the shutdown notifications only in the parent process and that `GetCurrentShutdownPhase` might not give the correct result in child processes. We might want to file a follow up bug that adds some asserts to avoid improper use of `AppShutdown` functions in child processes (but I do not want to make this patch bigger as needed to solve the blocking dependency for bug 1697972).
# The socket process is one example of a child process that "overloads" shutdown topics. I was wondering if it is the right call to use the very same topic names here to request shutdown to the socket process or if it should have its own topics. Those topics triggered the assert and thus I had to disable it for child processes, for now.
# This goes together with the more general approach to define process type specific shutdown phases (and hence mappings to topics) as drafted very roughly in bug 1697745.
# This patch seemed to trigger a known intermittent more often, thus the change here in `ServiceWorkerManager`.
Differential Revision: https://phabricator.services.mozilla.com/D124350
Add `NS_ConvertUTF16toUTF8::NS_ConvertUTF16toUTF8(const Span<const char16_t>)` and `NS_ConvertUTF16toUTF8::NS_ConvertUTF8toUTF16(const Span<const char>)` explicit constructors.
This is consistent with `NS_ConvertASCIItoUTF16` that already had one.
More importantly, other constructors were calling `AppendUTF{16,8}To{8,16}` functions taking a `Span`, so for cases where the caller already has a `Span` it's most efficient to have constructors accepting that `Span` directly.
Differential Revision: https://phabricator.services.mozilla.com/D125146
Andreea Pavel
Barret Rennie
Butkovits Atila
Sandor Molnar
Csoregi Natalia
Nika Layzell
Jari Jalkanen
Jan Varga
Randell Jesup
kriswright
Noemi Erli
Mike Hommey
Andi-Bogdan Postelnicu
Haik Aftandilian
Agi Sferro
Andreas Pehrson
Kershaw Chang
Iulian Moraru
Riya
Jon Coppeard
Jens Stutte
Marian-Vasile Laza
Byron Campen
Gerald Squelart
Cristian Tuns