This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
The exact circumstances of how this is showing up in the wild aren't
clear - there seem to be a couple of ways we can get here. However it
all revolves around early shutdowns (i.e., from the select profile popup)
- before the StartupCache is ever initialized. In any case, the solution
shouldn't change based on the exact circumstances - if we don't have a
StartupCache, there's no need to write one. Also, don't bother lazy
initializing it if it doesn't exist yet.
Differential Revision: https://phabricator.services.mozilla.com/D63208
--HG--
extra : moz-landing-system : lando
The patch removes the tad odd interleave behavior from the main thread and makes RefreshDriver to give
at least a tiny bit time for non-high priority tasks.
Given the recent change to have similar block-until behavior in child and parent process, this should work
consistently in all the processes.
Differential Revision: https://phabricator.services.mozilla.com/D63098
--HG--
extra : moz-landing-system : lando
This change is a little gross, because we don't totally control where
the statically initialized instances of `RWLock` live, due to its uses
in third-party libraries.
Differential Revision: https://phabricator.services.mozilla.com/D62936
--HG--
extra : moz-landing-system : lando
When we support `InputEvent.getTargetRanges()`, editor needs to create
`StaticRange` instances at starting to handle every edit operations/commands.
Therefore, we need a hack for saving allocation cost like `nsRange`.
This patch moves `nsRange::MaybeCacheToReuse()` and `nsRange::Shutdown()` to
`AbstractRange` to reduce copy&paste same code into `nsRange` and `StaticRange`.
However, `Create(nsINode*)` and `Release()` are duplicated unfortunately.
Differential Revision: https://phabricator.services.mozilla.com/D62692
--HG--
extra : moz-landing-system : lando
TSan reports a benign race when accessing a string between main thread and IPDL background thread. The reason is that we use `memory_order_relaxed` to check the reference count of StringBuffer. To avoid the benign race, this patch uses `memory_order_acquire` to perform acquire memory synchronization only for TSan build.
Differential Revision: https://phabricator.services.mozilla.com/D57620
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).
Differential Revision: https://phabricator.services.mozilla.com/D62295
--HG--
extra : source : d79f1d283acde1a971fe0e5e6f1a8db075f8589a
extra : histedit_source : 32a2b4fec1fcf35960155b0f4280a38bcb54ec19
The initial thought for getting the StartupCache out of the shutdown
path was to simply not write it during shutdown, as it should write
60 seconds after startup, and the theory was that if the user shut
down within the first 60 seconds of use, they were likely updating or
something and it shouldn't matter. However, considering how many of
our users only ever open one tab, I think it's rather likely that
users are starting up firefox to go to a web site, then closing it
when done with that website, and then maybe opening up a new instance
in order to go to a different website. Accordingly it still makes
sense to continue writing it. However, we may as well leverage a
background thread for this and get it kicked off earlier during
shutdown, so we don't sit there blocking in the destructor late
during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D62294
--HG--
extra : source : 7b7b147b6955cee07e0c115993446bfbd59cf7e2
extra : histedit_source : 6990122d6b1ac4939b0e4b0a5e452183fb981e19
Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).
Differential Revision: https://phabricator.services.mozilla.com/D62295
--HG--
extra : moz-landing-system : lando
The initial thought for getting the StartupCache out of the shutdown
path was to simply not write it during shutdown, as it should write
60 seconds after startup, and the theory was that if the user shut
down within the first 60 seconds of use, they were likely updating or
something and it shouldn't matter. However, considering how many of
our users only ever open one tab, I think it's rather likely that
users are starting up firefox to go to a web site, then closing it
when done with that website, and then maybe opening up a new instance
in order to go to a different website. Accordingly it still makes
sense to continue writing it. However, we may as well leverage a
background thread for this and get it kicked off earlier during
shutdown, so we don't sit there blocking in the destructor late
during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D62294
--HG--
extra : moz-landing-system : lando
Without this we can run into stack overflows caused by unoptimized Rust
code.
Differential Revision: https://phabricator.services.mozilla.com/D62476
--HG--
extra : moz-landing-system : lando
Gets rid of `NS_NewThread`. Where it was used in testing, I gave the new named threads names relevant to their tests.
Differential Revision: https://phabricator.services.mozilla.com/D62475
--HG--
extra : source : 541b98270c9985c5bd3569ff3ff8bc6c3d3c650a
Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).
Depends on D62294
Differential Revision: https://phabricator.services.mozilla.com/D62295
--HG--
extra : moz-landing-system : lando
The initial thought for getting the StartupCache out of the shutdown
path was to simply not write it during shutdown, as it should write
60 seconds after startup, and the theory was that if the user shut
down within the first 60 seconds of use, they were likely updating or
something and it shouldn't matter. However, considering how many of
our users only ever open one tab, I think it's rather likely that
users are starting up firefox to go to a web site, then closing it
when done with that website, and then maybe opening up a new instance
in order to go to a different website. Accordingly it still makes
sense to continue writing it. However, we may as well leverage a
background thread for this and get it kicked off earlier during
shutdown, so we don't sit there blocking in the destructor late
during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D62294
--HG--
extra : moz-landing-system : lando
Gets rid of `NS_NewThread`. Where it was used in testing, I gave the new named threads names relevant to their tests.
Differential Revision: https://phabricator.services.mozilla.com/D62475
--HG--
extra : moz-landing-system : lando
Every day clang's warnings continue to amaze me. As does our ability to trigger them.
I'm assuming that this line was meant to go within the scope of the `if`, because if it were outside the scope, then we'd be duplicating the previous `fprintf`.
Differential Revision: https://phabricator.services.mozilla.com/D61835
--HG--
extra : moz-landing-system : lando
If we're in a fast shutdown, we don't care about cleaning up anything -
we just want to get the profile saved if the env var is set up for doing
so.
Differential Revision: https://phabricator.services.mozilla.com/D61598
--HG--
extra : moz-landing-system : lando
Csoregi Natalia
Mike Shal
Boris Zbarsky
Simon Giesecke
Dorel Luca
Kershaw Chang
Christoph Walcher
Doug Thayer
Olli Pettay
Nathan Froyd
Masayuki Nakano
Cosmin Sabou
Brindusan Cristian
Tuan
shindli
Jeff Muizelaar
Kristen Wright
Ciure Andrei
Andreea Pavel
ffxbld
Jeff Walden
Nika Layzell
David Major
Valentin Gosu
Christian Holler