Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
NS_InitXPCOM() is currently not called in Gecko. It has been a one-line wrapper around NS_InitXPCOM2() since the year 2000 (bug 46320), presumably to maintain ABI compatibility for third-party users of XPCOM. We no longer need to worry about XPCOM ABI compatibility.
https://searchfox.org/mozilla-central/commit/cddb62593d786e0ff12b25037c74b01cb1a802e5
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
xpcom/build/XPCOMInit.cpp:187:1 [-Wmissing-prototypes] no previous prototype for function 'NS_InitXPCOM'
Differential Revision: https://phabricator.services.mozilla.com/D23266
--HG--
extra : rebase_source : 0ad5580e2978a8d5141bd6a9623c5af7359c78ca
extra : source : a9e4205868dbb847c01980051a56e99ad24a8ac1
The only difference between ShutdownLoaders and ShutdownFinal was an observer service shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D18389
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
vpx_mem_set_functions support is only enabled when
MOZ_VPX_NO_MEM_REPORTING is not set. It is currently set unconditionally
when building with the in-tree libvpx. When building with system libvpx,
it is set when the vpx_mem_set_functions can't be found in the system
libvpx library.
Upstream removed the vpx_mem_set_functions function in version 1.5, and
we require at least that version, meaning, in practice,
MOZ_VPX_NO_MEM_REPORTING is now always set.
We might as well remove the define and the code that's conditional to
not being defined.
Differential Revision: https://phabricator.services.mozilla.com/D14517
--HG--
extra : moz-landing-system : lando
After the previous patches, we no longer rely on the component manager
to incidentally start up XPConnect when we load the JS loader service
or to hold the JS component loader alive, so the do_GetService() call
for the JS loader in XPCOMInit.cpp can be removed. After that is done,
the JS loader is no longer used as an XPCOM component, so all of the
boilerplate for that can be removed.
Depends on D8757
Differential Revision: https://phabricator.services.mozilla.com/D8758
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
The NS_NewTimer* family of functions, when using a custom event target,
currently go through a path that looks something like:
auto timer = createTimer()
timer->SetTarget(target);
// call the requisite Init* function
return timer;
This setup is inefficient, because SetTarget requires the timer mutex to
be acquired. The mutex acquisition here is completely unnecessary,
because the timer hasn't yet been shared out to the wider world; we can
set the timer target without acquiring the mutex at all because we know
that no sharing is possible at this point.
This patch reworks things somewhat to make that possible.
Static atom registration is a bit of a mess. NS_InitAtomTable() calls
nsGkAtoms::RegisterStaticAtoms(), which calls NS_RegisterStaticAtoms(); i.e. we
go from nsAtomTable.cpp to nsGkAtoms.cpp and back.
(And NS_RegisterStaticAtoms() is declared in a .cpp file, not a .h file!)
This commit makes NS_InitAtomTable() a friend of nsGkAtoms, so NS_InitAtomTable
can see nsGkAtoms's atoms array directly, thus removing the need for
NS_RegisterAtomTable() and nsGkAtoms::RegisterStaticAtoms().
This commit also removes an out-of-date part of a comment from XPCOMInit.cpp.
--HG--
extra : rebase_source : 7e1f9aa0a9f7cb5088159fe4c953948b931f6d68
Emilio Cobos Álvarez
Gurzau Raul
Gijs Kruitbosch
Razvan Maries
Matt Woodrow
Michael Froman
Mike Hommey
Sylvestre Ledru
Chris Peterson
Honza Bambas
Kris Maglione
arthur.iakab
Adrian Wielgosik
Noemi Erli
Dana Keeler
Andy Wingo
Cosmin Sabou
Greg Tatum
Dragana Damjanovic
Ehsan Akhgari
Bogdan Tara
Dorel Luca
Andrew McCreight
Nathan Froyd
Daosheng Mu
Ciure Andrei
Stephen A Pohl
Nicholas Nethercote