Previously we inspected the `TASKCLUSTER_WORKER_GROUP` environment variable,
which now only returns the cloud provider of the worker. This commit teaches
`run-task` to instead use the `TASKCLUSTER_WORKER_LOCATION` to gather
information about the location of the worker. We also use the extra data
about the cloud provider for the worker to construct a key for use in the
config, in the form `cloudprovider/region`, so GCP hgweb mirrors can be
amended to the `hgmointernal` config when they are ready.
While we're here we make the error handling for a missing environment
variable slightly nicer.
Differential Revision: https://phabricator.services.mozilla.com/D53209
--HG--
extra : moz-landing-system : lando
Switch 'mach test-info report' and 'mach test-info tests' to use the TestManifestLoader.
Differential Revision: https://phabricator.services.mozilla.com/D54053
--HG--
extra : moz-landing-system : lando
This has the side effect of updating all debian10-based docker images
(except the ones based on debian10-test)
Differential Revision: https://phabricator.services.mozilla.com/D54069
--HG--
extra : moz-landing-system : lando
In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.
If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.
Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.
Differential Revision: https://phabricator.services.mozilla.com/D52566
--HG--
extra : moz-landing-system : lando
This is similar to [[current frame]] in Web Audio, but is in GraphTime,
not AudioContext-specific time.
Depends on D54083
Differential Revision: https://phabricator.services.mozilla.com/D54084
--HG--
extra : moz-landing-system : lando
After reading prelude, create HuffmanDictionaryForMetadata from
HuffmanDictionary and TemporaryStorage, and store it in metadata,
and use it while reading tree.
Differential Revision: https://phabricator.services.mozilla.com/D52957
--HG--
extra : moz-landing-system : lando
HuffmanDictionaryForMetadata behaves similar to HuffmanDictionary.
HuffmanDictionary is used while reading prelude, to store intermediate state.
HuffmanDictionaryForMetadata is used after reading prelude, to store the
complete state of the dictionary, with single chunk of memory.
HuffmanDictionaryForMetadata has payload to store items that is linked from
tables.
Differential Revision: https://phabricator.services.mozilla.com/D52956
--HG--
extra : moz-landing-system : lando
TemporaryStorage is used while reading prelude, to store instances of
HuffmanEntry etc, and tables store mozilla::Span to point items there.
Each instances are allocated inside TemporaryStorageItem, that manages
a linked list of item chunks, to reduce the amount of alloc/free,
to avoid unnecessary mutex lock inside allocator.
After reading prelude, items inside TemporaryStorage are supposed to be
moved to metadata payload, and Spans in tables are supposed to be updated to
point corresponding range.
Differential Revision: https://phabricator.services.mozilla.com/D52954
--HG--
extra : moz-landing-system : lando
This adds BinASTSourceMetadata{Multipart,Context} as subclasses of
BinASTSourceMetadata, with different fields for storing metadata.
Basically this is specialization of Variant, but given metadata has
payload after the class body itself, it doesn't work well with Variant.
Differential Revision: https://phabricator.services.mozilla.com/D52953
--HG--
extra : moz-landing-system : lando
This is preparation for bug 1555387, to store initialized GenericHuffmanTable
instances in contiguous space.
Differential Revision: https://phabricator.services.mozilla.com/D52952
--HG--
extra : moz-landing-system : lando
Hide the internal of status and table creation/access from consumers.
Depends on D52032
Differential Revision: https://phabricator.services.mozilla.com/D52034
--HG--
extra : moz-landing-system : lando
For bug 1593922, merged tables/status for field and list length.
Depends on D52029
Differential Revision: https://phabricator.services.mozilla.com/D52030
--HG--
extra : moz-landing-system : lando
To store dictionary to BinASTSourceMetadata, JSAtom* needs to be stored
in the single place.
Depends on D52028
Differential Revision: https://phabricator.services.mozilla.com/D52029
--HG--
extra : moz-landing-system : lando
The context format doesn't use Vector<BinASTKind>.
To avoid creating temporary Vector<BinASTKind> instance, added
BinASTSourceMetadata::Create without Vector<BinASTKind> parameter.
Differential Revision: https://phabricator.services.mozilla.com/D52028
--HG--
extra : moz-landing-system : lando
The basic idea, suggested by Olli, is that we can try to get a runnable in
ThreadEventQueue::GetEvent, and if that does not produce anything unlock our
mutex, do whatever idle state updates we need to do, re-lock our mutex. Then
always we need to try getting a runnable again, because a non-idle runnable
might have gotten queued while we had the lock unlocked. So we can't sleep on
our mutex, in the mayWait case, unless we try to get a runnable again first.
My notes on the current (pre this patch) unlocking setup follow.
------------------------------------------------------------
There are four places where we currently unlock:
1) IdlePeriodState::GetIdleDeadlineInternal. Needed only when !aIsPeek, to
RequestIdleToken, which can do IPC. The only caller, via
GetDeadlineForIdleTask, is PrioritizedEventQueue::GetEvent and only when we
selected the idle or deferred queue. We need this to set the proper deadline
on the idle event. In the cases when this unlock happens we currently _never_
return an idle event, because if we got here that means that we do not have an
idle token.
2) IdlePeriodState::GetLocalIdleDeadline. Needs to unlock to get the idle
period hint. The can get called from GetIdleDeadlineInternal in _both_ cases:
peek and get. The callstack for the get case is covered above. The peek case
is called from PrioritizedEventQueue::HasReadyEvent which is called from
ThreadEventQueue::HasPendingEvent.
3) IdlePeriodState::SetPaused, because it sends an IPC message. This is only
called from EnsureIsPaused, which is called from:
- IdlePeriodState::GetIdleDeadlineInternal. Only in the !aIsPeek case.
- IdlePeriodState::RanOutOfTasks called from:
- PrioritizedEventQueue::GetEvent if we fell into the idle case and our
queues are empty.
- PrioritizedEventQueue::DidRunEvent if we are empty.
4) IdlePeriodState::ClearIdleToken because it sends an IPC message. This is
called from:
- IdlePeriodState::RanOutOfTasks; see SetPaused.
- IdlePeriodState::GetIdleDeadlineInternal like EnsureIsPaused.
- IdlePeriodState::GetIdleToken if token is in the past. This is only
called from GetIdleDeadlineInternal, both cases.
- IdlePeriodState::FlagNotIdle called from PrioritizedEventQueue::GetEvent
if we find an event in a non-idle queue.
Or rewriting in terms of API entrypoints on IdlePeriodState that might need to
unlock:
* Anything to do with getting deadlines, whether we are peeking or getting.
Basically, if we need an updated deadline we need to unlock.
* When we have detected we are completely out of tasks (idle or not) to run.
Right now we do that when either we're asked for an event and don't have one
or if we run an event and are empty after that (before unlocking!). But the
unlocking or not happens in nsThreadEventQueue::DidRunEvent, so separately
from the getting of the event. In particular, we are unlocked before we
enter DidRunEvent, and unlock again before we return from it, so we can do
whatever updates we want there.
* When we have detected that we have a non-idle event to run; this calls
FlagNotIdle.
Differential Revision: https://phabricator.services.mozilla.com/D53631
--HG--
extra : moz-landing-system : lando
* Remove some artifacts from the pandoc convertion
* Fix some url
* Improve the l&f
* make the rstcheck linter happy (used by mach lint)
* Remove some old content (a 2007 doc)
Differential Revision: https://phabricator.services.mozilla.com/D54275
--HG--
extra : moz-landing-system : lando
Andrei Oprea
Punam Dahiya
Sylvestre Ledru
Connor Sheehan
Geoff Brown
Kershaw Chang
Jesse Schwartzentruber
Mike Hommey
Yura Zenevich
Zibi Braniecki
Doug Thayer
Karl Tomlinson
prathiksha
Sam Foster
Ted Campbell
Tooru Fujisawa
Julian Descottes
Boris Zbarsky
Gabriele Svelto
Henrik Skupin