Relaxes the type constraints for span overloads on `nsTArray`, such as
`AppendElements`. They previously took `Span<const Item>`, which could cause
build errors when attempting to pass a non const-qualified Item such as in
`Span<RefPtr<BrowsingContext>>`.
Differential Revision: https://phabricator.services.mozilla.com/D71232
Prior to this patch, the startupcache created its own mWriteThread off which it
wrote to disk. It's initialized by MaybeSpawnWriteThread, which got called
at shutdown, to do the shutdown write if there was any reason to do so, and
from a timer that is re-initialized after every addition to the startup cache,
to run 60s after the last change to the cache.
It then joined that write thread on the main thread (in other words, blocks
on that off-main-thread write completing from the main thread) when:
- xpcom-shutdown fired
- the startupcache itself gets destroyed
- someone calls any of:
* HasEntry
* GetBuffer
* PutBuffer
* InvalidateCache
This patch removes the separate write thread, and instead dispatches a task to
the background task queue, indicating it can block. The task is started in
the same circumstances where we previously used to write (timer from the last
PutBuffer call, and shutdown if necessary).
To ensure it cannot be trying to use the data it writes out (mTable) from
the other thread while that data changes on the main thread, we use a mutex.
The task locks the mutex before starting, and unlocks when finished.
Enumerating the cases that we used to block on joining the thread:
In terms of application shutdown, we expect the background task queue to
either finish the write task, or fail to run it if it hasn't started it yet.
In the FastStartup case, we check if a write was necessary; if so, we
attempt to gain the lock without waiting. If we're successful, the write has
not yet started, and we instead run the write on the main thread. Otherwise,
we retry gaining the lock, blocking this time, thus guaranteeing the
off-the-main-thread write completes.
The task keeps a reference to the startupcache object, so it cannot be
destroyed while the task is pending.
Because the write does not modify `mTable`, and neither does `HasEntry`,
we do not need to do anything there.
In the `GetBuffer` case, we do not modify the table unless we have to read
the entry off disk (memmapped into `mCacheData`). This can only happen if
`mCacheData.initialized()` returns true, and we specifically call
`mCacheData.reset()` before firing off the write task to avoid this.
`mCacheData` is only re-initialized if someone calls `LoadArchive()`,
which can only happen from `Init()` (which is guaranteed not to run
again because this is a singleton), or `InvalidateCache()`, where we lock
the mutex (see below). So this is safe - but we assert on the lock to try
and avoid people breaking this chain of assumptions in the future.
When `PutBuffer` is called, we try to lock the mutex - but if locking fails
(ie the background thread is writing), we simply fail to store the entry
in the startupcache. In practice, this should be rare - it'd happen if
new calls to PutBuffer happen while writing during shutdown (when really,
we don't care) or when it's been 60 seconds since the last PutBuffer so
we started writing the startupcache.
When InvalidateCache is called, we lock the mutex - we shouldn't try to
write while invalidating, or invalidate while writing. This may be slow,
but in practice nothing should call `InvalidateCache` except developer
restarts or the `-purgecaches` commandline flag, so it shouldn't
matter a great deal.
Differential Revision: https://phabricator.services.mozilla.com/D70413
--HG--
extra : moz-landing-system : lando
Unlinking, such as in UnbindFromTree, can add runnables that keep alive CCed
objects after they have been unlinked. In combination with some unknown
fields not being traversed and unlinked this could cause intermittent shutdown
leaks, if those unknown fields hold alive objects that need the CC to be
collected. Work around this by clearing out these runnables after every
shutdown CC.
Also, fix the order of these two steps, which was apparently wrong
before.
Differential Revision: https://phabricator.services.mozilla.com/D71049
--HG--
extra : moz-landing-system : lando
This pattern:
```
native nsSize (nsSize);
^
```
Causes a parsing error in `ply` 3.10. This can be easily fixed by removing the space and reformatting to this:
```
native nsSize(nsSize);
```
Differential Revision: https://phabricator.services.mozilla.com/D70711
--HG--
extra : moz-landing-system : lando
L3 cache being present in /proc/cpuinfo is an Intel-ism. Use the cross-platform
/sys/devices instead.
Differential Revision: https://phabricator.services.mozilla.com/D70892
--HG--
extra : moz-landing-system : lando
The patch makes sure the checkSingleZoneHolders variable is always present. I expect it will get optimised away in builds where it's unused.
Differential Revision: https://phabricator.services.mozilla.com/D70818
--HG--
extra : moz-landing-system : lando
The patch makes sure the checkSingleZoneHolders variable is always present. I expect it will get optimised away in builds where it's unused.
Differential Revision: https://phabricator.services.mozilla.com/D70818
--HG--
extra : moz-landing-system : lando
One could possibly make larger changes to make the setup less error prone, but hopefully we'll
replace this code with the new scheduler relatively soon.
And the assertion there should still enforce correct behavior.
Differential Revision: https://phabricator.services.mozilla.com/D69988
--HG--
extra : moz-landing-system : lando
Through their use of Smprintf, the existing warning message formatting
is resistant to OOM errors. So I figured that we should probably use
something that doesn't infallibly allocate like GetErrorName does.
Differential Revision: https://phabricator.services.mozilla.com/D70771
--HG--
extra : moz-landing-system : lando
This commit removes `test_fix_stack_using_bpsyms.py`. That test can't easily be
modified to work with `fix_stacks.py` because it relies on internal
implementation details of `fix_stack_using_bpsym.py`. The unit testing done in
the `fix-stacks` repo provides test coverage that is as good or better.
Differential Revision: https://phabricator.services.mozilla.com/D66924
--HG--
extra : moz-landing-system : lando
The instantiations of the externed templates need to be in the same translation unit as the definitions. Currently they work due to building in unified mode.
Differential Revision: https://phabricator.services.mozilla.com/D69467
--HG--
extra : moz-landing-system : lando
This is necessary to avoid the use of setOriginAttributesBeforeLoading, which is
being removed in this patch set.
Differential Revision: https://phabricator.services.mozilla.com/D67042
--HG--
extra : moz-landing-system : lando
Also moves `nsThreadShutdownContext` to `nsThread.h` so it can be used by `nsThreadPool`.
Differential Revision: https://phabricator.services.mozilla.com/D69657
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
We cache this information in compatibility.ini so we can just expose it on
nsIXULRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D66112
--HG--
extra : moz-landing-system : lando
Robert Longson
Cosmin Sabou
Nika Layzell
Valentin Gosu
Konstantin Morozov
Gijs Kruitbosch
Andrew McCreight
Ricky Stewart
Kristen Wright
Chris H-C
Jon Coppeard
Bogdan Tara
Olli Pettay
Simon Giesecke
Tooru Fujisawa
Cameron McCormack
Nicholas Nethercote
Narcis Beleuzu
Honza Bambas
Emma Malysz
Matt Woodrow
Gerald Squelart
Eric Rahm
Marco Bonardo
Razvan Maries
Andreas Farre
Dave Townsend
Ciure Andrei
Mozilla Releng Treescript