The callsites now mostly use MakeAndAddRef (which just stuffs a new object into
a RefPtr and calls `forget()` to yield an already_AddRefed).
In cases where the callsite constructs the object earlier and retains a strong
reference, they'll now use do_AddRef to explicitly generate a strong reference
(as an already_AddRefed) to pass into RegisterStrongMemoryReporter.
Differential Revision: https://phabricator.services.mozilla.com/D299042
This reverts commit 1ab110ab2f.
Revert "Bug 2037761: Change RegisterStrongMemoryReporter to take already_AddRefed instead of a raw pointer, and update callsites. r=dom-core,smaug"
This reverts commit 2e187ddbc8.
The callsites now mostly use MakeAndAddRef (which just stuffs a new object into
a RefPtr and calls `forget()` to yield an already_AddRefed).
In cases where the callsite constructs the object earlier and retains a strong
reference, they'll now use do_AddRef to explicitly generate a strong reference
(as an already_AddRefed) to pass into RegisterStrongMemoryReporter.
Differential Revision: https://phabricator.services.mozilla.com/D299042
Bug 1579367 moved XPConnect `JSContext` creation (and `LoadStartupJSPrefs`)
during startup so that this happens after loading user prefs. This ensured
that modified JS startup prefs are handled correctly in the parent process.
This patch fixes a similar issue for `JS::Prefs` (which must be set before
calling `JS_InitWithFailureDiagnostic`) by moving process-wide JS engine
initialization to right before we create the first `JSContext`.
This also simplifies JS engine startup in Gecko because this now happens in one place.
Differential Revision: https://phabricator.services.mozilla.com/D279518
Bug 1579367 moved XPConnect `JSContext` creation (and `LoadStartupJSPrefs`)
during startup so that this happens after loading user prefs. This ensured
that modified JS startup prefs are handled correctly in the parent process.
This patch fixes a similar issue for `JS::Prefs` (which must be set before
calling `JS_InitWithFailureDiagnostic`) by moving process-wide JS engine
initialization to right before we create the first `JSContext`.
This also simplifies JS engine startup in Gecko because this now happens in one place.
Differential Revision: https://phabricator.services.mozilla.com/D279518
This doesn't even appear to be used by the one place that includes it.
I built XPCOMInit.cpp in non-unified and it seemed okay.
Differential Revision: https://phabricator.services.mozilla.com/D275120
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
Before this change, we would initialize IOThread much earlier during startup, before Preferences are available to read (which depends on the XPCOM component manager). After this change, starting the IOThread is done during XPCOM component startup, meaning preferences are available.
This will allow us to customize IPC configuration at startup based on Preferences in the parent process. Content processes still cannot depend on Prefs to be available.
Differential Revision: https://phabricator.services.mozilla.com/D256503
This reverts commit 50659c4eb4.
Revert "Bug 901050 - Part 5: Don't initialize IOThread until Prefs are available, r=ipc-reviewers,mccr8"
This reverts commit 8358951e9a.
Revert "Bug 901050 - Part 4: Use IPC::Channel::Mode to indicate brokering status, r=ipc-reviewers,jld"
This reverts commit 7added392b.
Revert "Bug 901050 - Part 3: Add an IPC::ChannelMach Backend, r=ipc-reviewers,jld"
This reverts commit 21f9270e40.
Revert "Bug 901050 - Part 2: Add mach port watching support to the IO thread, r=ipc-reviewers,jld"
This reverts commit 1cb4ea55a2.
Revert "Bug 901050 - Part 1: Make IPC::Channel virtual, r=ipc-reviewers,jld"
This reverts commit 0c9d93c0c2.
Before this change, we would initialize IOThread much earlier during startup, before Preferences are available to read (which depends on the XPCOM component manager). After this change, starting the IOThread is done during XPCOM component startup, meaning preferences are available.
This will allow us to customize IPC configuration at startup based on Preferences in the parent process. Content processes still cannot depend on Prefs to be available.
Differential Revision: https://phabricator.services.mozilla.com/D256503
We were using `NS_GetSpecialDirectory(NS_OS_DEFAULT_DOWNLOAD_DIR, ...)`
before for getting the download directory for the profiler POSIX signal
profiling. But this ignores the user-set download directory and always
use the default downloads folder. And while doing so, it creates this
default folder even if the user set it to another one.
Now we are using `GetPreferredDownloadsDirectory` directly which looks
for the user-set download directory first and uses it if it find one.
We had to change the location we call profiler_lookup_async_signal_dump_directory
because in that location user-defined prefs weren't fully initialized
yet in NS_InitXPCOM. Moved it inside `XREMain::XRE_mainRun`. Note that
there is a small behavior change here. Previously that function was
being called in *every process*, and now it's being called only in the
parent process. This is actually the desired behavior because we can't
capture profiles by directly sending POSIX signals to child processes
due to sandboxing restrictions.
Differential Revision: https://phabricator.services.mozilla.com/D254342
We were using `NS_GetSpecialDirectory(NS_OS_DEFAULT_DOWNLOAD_DIR, ...)`
before for getting the download directory for the profiler POSIX signal
profiling. But this ignores the user-set download directory and always
use the default downloads folder. And while doing so, it creates this
default folder even if the user set it to another one.
Now we are using `GetPreferredDownloadsDirectory` directly which looks
for the user-set download directory first and uses it if it find one.
We had to change the location we call profiler_lookup_async_signal_dump_directory
because in that location user-defined prefs weren't fully initialized
yet in NS_InitXPCOM. Moved it inside `XREMain::XRE_mainRun`. Note that
there is a small behavior change here. Previously that function was
being called in *every process*, and now it's being called only in the
parent process. This is actually the desired behavior because we can't
capture profiles by directly sending POSIX signals to child processes
due to sandboxing restrictions.
Differential Revision: https://phabricator.services.mozilla.com/D254342
We can defer the purging of arenas to happen during idle processing on the main thread.
We already have the following prerequisites thanks to bug 1488780:
- The (often) expensive OS functions to give back memory pages are not blocking the use of the arena on other threads anymore.
- A single call to moz_may_purge_one_now (D232083) wraps just arena_t::Purge() that will just do "some work on one chunk" and tell if more is needed, giving us a fine grained control.
Synchronous purging can block the caller of a memory freeing function for an unexpectedly long time. Furthermore, memory that might be reclaimed very soon can be madvised early and thus its reuse can lead to frequent page faults.
We thus use moz_enable_deferred_purge (see D232083) to queue purge requests and execute them on the main thread only if it is about to become idle. We do this using an IdleTaskRunner that ensures we won't purge too often or never.
We believe that the main thread being idle is probably the best easy indicator we have to tell if the process is idle enough to purge without performance regrets.
We expect the peak memory usage of a single arena to not be affected significantly by this during normal use, but the time that this peak holds up might extend. This means the peak sum of all memory from all running processes may rise for short periods of time until enough purges happened on potentially several processes.
There is a chance to mitigate this effect by lowering the settings of allowed dirty pages for arenas, as there should be less churn in general with this patch, potentially resulting in a lower memory usage in average.
Differential Revision: https://phabricator.services.mozilla.com/D220616
Previously the handling for the IO thread was split between
BrowserProcessSubThread (a replication of the background thread infrastructure
used by Chromium during the IPC import, which is only used for the IO thread in
Gecko), and IOThreadChild (a wrapper around ChildThread, which was imported
from Chromium's source).
This meant that there was little code-sharing between the parent and child
processes, and that the lifecycle of the IO thread was perhaps less clear.
This refactors the code to centralize handling of these threads, and provide a
basic common interface. At the moment, actually hooking up async IO listeners
is still done using the Chromium interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D227739
Previously the handling for the IO thread was split between
BrowserProcessSubThread (a replication of the background thread infrastructure
used by Chromium during the IPC import, which is only used for the IO thread in
Gecko), and IOThreadChild (a wrapper around ChildThread, which was imported
from Chromium's source).
This meant that there was little code-sharing between the parent and child
processes, and that the lifecycle of the IO thread was perhaps less clear.
This refactors the code to centralize handling of these threads, and provide a
basic common interface. At the moment, actually hooking up async IO listeners
is still done using the Chromium interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D227739
Omnijar::Init can detect corrupted zip files and react accordingly. It
cannot fail if omni.ja is just missing, as we might run in a
configuration where resources are loaded directly from the modules
directory. We thus add also a canary load of the AppConstants
module to XRE_mainRun as soon as we have a JS context.
Differential Revision: https://phabricator.services.mozilla.com/D205026
This adds a pref to disable jit compilation by calling JS::DisableJitBackend in
the parent process. This will be used on iOS, where the jit entitlements are
only available for sandboxed content processes.
Differential Revision: https://phabricator.services.mozilla.com/D203498
Daniel Holbert