StackMapGenerator::createStackMap() creates stack maps in the wasm baseline
compiler. For release builds, it first performs a check to determine whether
the stackmap would describe only non-ref words, and if so, exits without
creating the map, since the map would be useless.
To make the check cheaper, it is inexact but safe, so it sometimes causes a
map to be created even though it is unnecessary. Specifically, the vector
|extras|, which may contain a description of exit stub register save
locations, is regarded as possibly-contributing-refs if it is merely
non-empty. The actual contents are not checked. This causes creation of
33,688 unnecessary stack maps in the Tanks test case, probably one for each
function.
The fix is simple. Actually check every element of |extras| to see if any are
|true|. This makes the test exact, removes all unnecessary map creation, and
reduces the Tanks compile cost from 2.43 billion instructions to 2.39 billion
instructions. That is, the shortcut was overall a loss anyway, presumably due
to the extra costs incurred by the pointless stackmap creation.
--HG--
extra : rebase_source : 4990f28ec6d3d50e289432572c79a6ca105aecc3
We cannot move each block into separated methods while computing EventTargetData
because we need to check capturing contents, etc. Therefore, only each block
should be moved to separated methods for now.
This moves a block which computes event target from point of the event. If
this can be moved to EventTargetData, it might be easier to understand, but
its helper method GetFrameToHandleNonTouchEvent() requires to access members
of EventHandler. Therefore, we need to treat EventTargetData as an out param
of the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21189
--HG--
extra : moz-landing-system : lando
We now allow frames to have a negative time (so that they can be decoded and trimmed).
Differential Revision: https://phabricator.services.mozilla.com/D21474
--HG--
extra : moz-landing-system : lando
This is not strictly related to the rest of the patches, but it was annoying
me while I wrote them.
Differential Revision: https://phabricator.services.mozilla.com/D21450
--HG--
extra : rebase_source : d9fa9ce79e63c2098e74fd401ccaccf7bf22eabf
We already create early stub policy objects in the parent process during
extension startup, so that early load attempts and policy queries can succeed
during startup and extension installation. This patch does the same for child
processes, which likewise may be asked to load extension URLs early during
startup when they override the homepage or have pages loaded from session
restore.
Differential Revision: https://phabricator.services.mozilla.com/D21448
--HG--
extra : rebase_source : 189cecff691630336f38c16568f64350a5b2637c
We don't want extension protocol load requests to begin loading until the
extension is far enough initialized to run code. If we load it before then,
the extension framework will either fail to recognize the extension entirely,
or may begin running its scripts in an incomplete environment.
This patch adds a slow path which adds a promise handler and creats a stub
channel only in the case when the extension is not ready. In the normal,
already-initialized case, we take the more direct path.
Differential Revision: https://phabricator.services.mozilla.com/D21447
--HG--
extra : rebase_source : ca770d241ff68192716feace67cd512565ae6b24
This adds a promise member to the stub WebExtensionPolicy objects that we
create early during extension initialization which resolves when the real
extension instance is ready to load content. This promise will be used by the
extension protocol handler to delay loads until the framework is ready to
handle them.
Differential Revision: https://phabricator.services.mozilla.com/D21445
--HG--
extra : rebase_source : 14dccdc7c955b97879e8b93cf11f18b61723ed18
And remove the manual --enable-dmd in in-tree mozconfigs, as well as
--enable-profiling, which is implied by --enable-dmd.
This disables DMD on add-on-devel builds, which don't look like they
were actually meant to have DMD enabled in the first place (they only do
because they use the nightly mozconfig on all branches, and as a matter
of fact, the nightly mozconfig didn't enable DMD before bug 1409739)
This enables DMD on mingw builds with the same conditions applied as
other platforms, meaning that it's not enabled on opt builds on release
branches.
And this enables DMD on plain builds, which, from this perspective,
reflect local developer builds, and this is the expected effect.
Depends on D21161
Differential Revision: https://phabricator.services.mozilla.com/D21162
--HG--
extra : moz-landing-system : lando
These are trivial issues that I'd rather keep out of the main patch.
Differential Revision: https://phabricator.services.mozilla.com/D21444
--HG--
extra : rebase_source : c607248dd2d44673b84f4bc99464c3f15a639add
This patch moves adding the event handlers into MozTree.connectedCallback. This allows <tree onkeydown="...."> to function properly.
The patch also folds all the 10 handlers for keydown into one, and handling the different cases in a switch.
This is more complex than merely modifying NS_GetDefaultReferrerPolicy()
because at the time most (all?) callers call nsIHttpChannel::SetReferrer/
nsIHttpChannel::SetReferrerWithPolicy before the channel is opened,
which means we won't know whether the channel is a tracking resource or
not yet. So we would need to re-evaluate this decision after that
information becomes available. For that, we need to remember the
original URI argument passed to these functions since that information
is currently destroyed and isn't persisted anywhere in the system.
Differential Revision: https://phabricator.services.mozilla.com/D20901
--HG--
extra : moz-landing-system : lando
After landing bug 1515004, it is unnecessary to use `--with-android-sdk` when
developer uses default path of Android SDK by `./mach bootstrap`.
So let's remove `--with-android-sdk` from mozconfig example using
`./mach bootstrap`.
Differential Revision: https://phabricator.services.mozilla.com/D20601
--HG--
extra : moz-landing-system : lando
Depends on D20471
I can drop this changeset if we prefer, but this is how I imagine the disconnect button would fit in the RuntimeInfo.
Differential Revision: https://phabricator.services.mozilla.com/D20472
--HG--
extra : moz-landing-system : lando
Kai Engert
Jeff Walden
Julian Seward
Daniel Varga
Masayuki Nakano
Boris Zbarsky
Ciure Andrei
Dorel Luca
Jean-Yves Avenard
Kris Maglione
Mike Hommey
Csoregi Natalia
Gurzau Raul
Bogdan Tara
Brian Hackett
Nicholas Nethercote
Daosheng Mu
Emilio Cobos Álvarez
Johann Hofmann
Andrew Erickson
shindli
Magnus Melin
Andrew Halberstadt
Ehsan Akhgari
Ryan VanderMeulen
Alexis Beingessner
Makoto Kato
Nicolas Chevobbe
Oana Pop Rus
Robert Strong
Sam Foster
Julian Descottes