This patch alone decreases the runtime of the loop on my machine from about
1700 to 200-400ms ranges. It turns out that computing the type index is
the most expensive part. So perhaps we should look into improving that as
well.
The first thing that comes to mind is whether we can inline the loop in
GetTypeIndex(). The next part takes care of that, and it does help a bit.
But we need to do more still.
The next obvious thing is to optimize the memory access patterns. Right
now we iterate over an array of dynamically allocated strings to compare
them, which amounts to pointer chasing to read a bit of memory, kind of
the worst possible way to access memory. Then we look at replacing that
with fully sequential memory reads in the common cases.
Depends on D20231
Differential Revision: https://phabricator.services.mozilla.com/D20232
--HG--
extra : moz-landing-system : lando
We choose 100,000 iterations so that on a fast processor the test takes
times in the order of seconds.
Differential Revision: https://phabricator.services.mozilla.com/D20229
--HG--
rename : extensions/cookie/test/moz.build => extensions/cookie/test/gtest/moz.build
extra : moz-landing-system : lando
This fixes frequent jsreftest OOMs on Win32 because we weren't triggering GC
frequently enough. Bug 1377131 changed the timer ordering in this code and might
have regressed this.
Differential Revision: https://phabricator.services.mozilla.com/D20664
--HG--
extra : moz-landing-system : lando
Android requires us to use -fprofile-generate / -fprofile-use instead of
-fprofile-instr-generate / -fprofile-instr-use. Additionally, we have
to pass in the path to write out the profile data as /data/local/tmp,
since the cwd from where the Fennec process is invoked is not writeable.
Differential Revision: https://phabricator.services.mozilla.com/D20697
--HG--
extra : moz-landing-system : lando
It won't change then, even when removed from the UA Widget. It also gives us an
extra node bit.
Differential Revision: https://phabricator.services.mozilla.com/D20560
--HG--
extra : moz-landing-system : lando
I only converted a few low hanging fruits to the new API. Having to check for PrivateGCThing, which often can't even appear is a bit annoying, but I don't think we really need a different type.
I think next I can look into some of the extractNonDoubleType uses.
Differential Revision: https://phabricator.services.mozilla.com/D20474
--HG--
extra : moz-landing-system : lando
Instead of having cache misses for all variables that may vary when
getting job details. While the currently used variables are mostly
constants, we're going to introduce some flexibility in an subsequent
change.
Depends on D20443
Differential Revision: https://phabricator.services.mozilla.com/D20444
--HG--
extra : moz-landing-system : lando
Once all tests regexp are gone, we come to realize that all the package
regexp are the same for each ArtifactJob subclass, some we move the
definitions to the subclasses.
Depends on D20442
Differential Revision: https://phabricator.services.mozilla.com/D20443
--HG--
extra : moz-landing-system : lando
Once the firefox-* and fennec-* regexp are gone, we come to realize
that all jobs have the same regexp for tests, so we can just
use that across the board and remove the definition from JOB_DETAILS.
Depends on D20441
Differential Revision: https://phabricator.services.mozilla.com/D20442
--HG--
extra : moz-landing-system : lando
The filters were added back when buildbot was still used, and some
artifacts were still using file names beginning with "firefox" or
"fennec".
That is not true now that all builds are on taskcluster, and for all of
them, they are now target.$ext.
Differential Revision: https://phabricator.services.mozilla.com/D20441
--HG--
extra : moz-landing-system : lando
It wasn't clear in callee code that the window was the top-window and it wasn't necessary in many cases. Relying on the top-window would also cause problems with Fission if the windows are in separate processes.
Differential Revision: https://phabricator.services.mozilla.com/D20395
--HG--
extra : moz-landing-system : lando
There were too many top-level objects in that large JSM and LoginHelper didn't exist when it was added.
Differential Revision: https://phabricator.services.mozilla.com/D20393
--HG--
extra : moz-landing-system : lando
This means there is only one signon.* listener for the whole process, not per-logger.
Also move LMC prefs to LMH.
Differential Revision: https://phabricator.services.mozilla.com/D20391
--HG--
extra : moz-landing-system : lando
We use the SHIELD pref instead of the usual launcher process pref for Nightly.
This effectively treats the launcher process as a SHIELD study with 100%
deployment.
We add some Nightly-specific code that uses the SHIELD pref to determine
whether or not to use the launcher. During startup, we query that pref and
reflect it into the registry, which then falls through to the usual launcher
process code.
We will be changing this past 67, but for now this is an effective way to
provide Nightly users with an opt-out to the launcher process and its telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D20621
--HG--
extra : moz-landing-system : lando
The idea here is that the installer always disables by default, but then
Firefox itself later re-enables when the appropriate pref is turned on.
I also added a check for the third launcher process registry key (|Image)
since we really only want to do this when all three registry values are
nonexistent.
Differential Revision: https://phabricator.services.mozilla.com/D20620
--HG--
extra : moz-landing-system : lando
Type barriers are marked as Guard instructions, however, in OSR blocks guards
are eligible for DCE. However, Null/Undefined/MagicOptimizedArguments have no uses
associated with them, and so get optimized out. To prevent that, this patch
uses the ImplicitlyUsed flag to indicate to DCE that these barriers are not
eligible for elimination.
Differential Revision: https://phabricator.services.mozilla.com/D20388
--HG--
extra : moz-landing-system : lando
Now that the base Target class is managing the thread client,
we no longer have to send "newSource" on the target actor, and instead,
listen for newSource directly on the thread client.
We should probably align updatedSource and have this event being emitted on
the thread actor as well.
Depends on D18813
Differential Revision: https://phabricator.services.mozilla.com/D18814
--HG--
extra : moz-landing-system : lando
There is still some tight connection between ThreadClient and Target,
- Target.threadClient, which should ideally disappear in favor of
target.getFront("thread")
- Target.threadClient is manually nullified from ThreadClient.detach,
but that should disappear as well thanks to getFront.
Differential Revision: https://phabricator.services.mozilla.com/D18813
--HG--
extra : moz-landing-system : lando
The AutoDebuggerJobQueueInterruption destructor asserts that the Debugger has
properly managed its hooks' asynchronous jobs. But this assertion clearly only
applies when the AutoDebuggerJobQueueInterruption is properly initialized;
otherwise, the debuggee's job queue is still in place.
Unfortunately, the destructor was using the wrong test to determine whether the
debuggee's queue had been saved. This patch makes it uses the `initialized`
method, rather that checking the `cx` field, which is always initialized.
Differential Revision: https://phabricator.services.mozilla.com/D20575
--HG--
extra : moz-landing-system : lando
Using this flag will cause GeckoWebExecutor.fetch() to not automatically
follow redirects, which is the default behavior if no flag is specified.
Differential Revision: https://phabricator.services.mozilla.com/D19523
--HG--
extra : moz-landing-system : lando
This simply lets you request 'count' random bytes. A SHA-256 digest is
included for verifying the integrity of the response.
Differential Revision: https://phabricator.services.mozilla.com/D19503
--HG--
extra : moz-landing-system : lando
A JSScript can be explicitly cloned and applied to a new realm. When this is done within the same compartment
as the original JSScript, it maintains its reference to the original ScriptSourceObject. This can lead to the
potentially surprising fact that using Debugger.findScripts({ source }) can return multiple Debugger.Script
objects representing the same function, but in multiple realms.
When we query for breakpoints in a given source, we want to take the first column breakpoint on a given line,
but that needs to apply to all potential instances of the Debugger.Script for that location, not just the first one.
Differential Revision: https://phabricator.services.mozilla.com/D20431
--HG--
extra : moz-landing-system : lando
I'm not really sure why Flask isn't printing this for us, but it's not worth
investigating when the alternative is so easy.
Differential Revision: https://phabricator.services.mozilla.com/D20712
--HG--
extra : moz-landing-system : lando
Ehsan Akhgari
Cameron McCormack
Shivam Singhal
Jan de Mooij
Mike Shal
Kartikaya Gupta
Felipe Gomes
Emilio Cobos Álvarez
Tom Schuster
Dão Gottwald
Mike Hommey
Bogdan Tara
Matthew Noorenberghe
Andy Wingo
Yura Zenevich
Ting-Yu Lin
Nika Layzell
Marco Bonardo
Aaron Klotz
Matthew Gaudet
Alexandre Poirot
Jim Blandy
James Willcox
Logan Smyth
Andrew Halberstadt