This is necessary for the next patch: it will merge JSOP_LOOPHEAD
and JSOP_LOOPENTRY but that means there can be multiple callVMs for
that op and this confuses DebugModeOSR (interrupts can trigger debugger
recompilation).
Differential Revision: https://phabricator.services.mozilla.com/D55631
--HG--
extra : moz-landing-system : lando
In visitTestBackedge we can just get the backedge target from the
bytecode instruction.
Differential Revision: https://phabricator.services.mozilla.com/D55629
--HG--
extra : moz-landing-system : lando
All loops now use State::DoWhileLike so we can don't need to keep track of the
state anymore and can remove some more dead code.
Differential Revision: https://phabricator.services.mozilla.com/D55628
--HG--
extra : moz-landing-system : lando
All loops now have the same structure. A later patch in the stack
will remove this class.
Differential Revision: https://phabricator.services.mozilla.com/D55626
--HG--
extra : moz-landing-system : lando
This changes all loops to have the following bytecode structure:
```
JSOP_LOOPHEAD
JSOP_LOOPENTRY
...condition/body...
JSOP_GOTO/JSOP_IFEQ/JSOP_IFNE
```
This simplifies IonBuilder a lot because it can use the do-while code path
for all loops. For-in loops are also a bit simpler now because they no longer
need to have the next enumerated value on the stack across the backedge.
Later patches in the stack wil fold JSOP_LOOPENTRY into JSOP_LOOPHEAD,
simplify the source notes more and remove more code from IonBuilder.
I verified stepping/breakpoints for the different loop types works in the
debugger the same way as before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D55625
--HG--
extra : moz-landing-system : lando
The old code used the beforeLoopEntry bytecode pc, but this wasn't always
the correct pc and fixing that is a bit annoying (IonBuilder would have to
keep track of the last pc just for this).
Differential Revision: https://phabricator.services.mozilla.com/D55624
--HG--
extra : moz-landing-system : lando
The size of the visible region, for either a painted layer or a webrender blob
image, is calculated from the building rects of the contained display items, in
local-space. This should be restricted to the display port, to prevent the
visible regions growing too large leading to excessive memory usage.
For items within large scale transforms, the local-space visible region should
be very small. However, as we do not allow fractional sizes, the size of the
visible region will be rounded up to at least 1. This means that when we convert
the region back to screen-space, we are multiplying the extremely large scale by
at least one, rather than by a much smaller fraction. This can result in
incredibly large visible regions, and was causing OOM crashes.
To avoid this, we clamp the maximum chosen scale for these layers/blob images to
32k. Layers affected by this problem should have a visible region with
dimensions of 1 or 2, so this limits the resulting screen-space size for
those to an acceptable value. Layers with visible regions sized greater than
that should not have scales anywhere near this large, so will not be affected.
Differential Revision: https://phabricator.services.mozilla.com/D55691
--HG--
extra : moz-landing-system : lando
In bug 1531142 we made it so that when a spatial node is being pinch-zoomed we
use a local raster-space to avoid rerasterizing glyphs for every slight change
in zoom level. This makes it so that we also apply the same trick when
being asynchronously zoomed by a double-tap gesture.
Differential Revision: https://phabricator.services.mozilla.com/D55699
--HG--
extra : moz-landing-system : lando
This is part 2 of a series of revs that split up D41710 (for Wasm I64 to BigInt conversion) into smaller revs. This rev depends on the compile-time flag added in D43177 and adds a runtime flag to JSContext options that will toggle whether I64 to BigInt conversion is used. The flag will get used mostly in WasmInstance.cpp, but it also needs to be used to toggle I64 error checks in both Ion inlining code and in Wasm stub generation code. To pass that information along, the flag is also put in CompileArgs for WasmCompile and then copied to wasm module metadata (so that it can be read from lazy stub generation code).
Differential Revision: https://phabricator.services.mozilla.com/D43179
Icons added after the initial parsing are likely randomly generated to show badges,
thus they are not good for permanent storage, because they are transient and can
potentially flood the store.
Differential Revision: https://phabricator.services.mozilla.com/D55310
--HG--
extra : moz-landing-system : lando
Bug 1601233 made cranelift bump its syn dependency to 1.0, breaking the
workspace hack. Some of the features were also stale from presumably
other updates.
Differential Revision: https://phabricator.services.mozilla.com/D55897
--HG--
extra : moz-landing-system : lando
This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
extra : moz-landing-system : lando
Class ForkServer and class ForkServiceChild are implemented. The
chrome process can ask the fork server process to create content
processes. The requests are sent by MiniTransceiver over a socket.
The fork server replys with the process IDs/handles of created
processes.
LaunchOptions::use_forkserver is a boolean. With use_forkserver being
true, the chrome process sends a request to the fork server instead of
forking directly.
Depends on D46881
Differential Revision: https://phabricator.services.mozilla.com/D46883
--HG--
extra : moz-landing-system : lando
MiniTransceiver is a simple request-reponse transport, always waiting
for a response from the server before sending next request. The
requests are always initiated by the client.
Depends on D46880
Differential Revision: https://phabricator.services.mozilla.com/D46881
--HG--
extra : moz-landing-system : lando
An instance of AppForkBuilder creates a new content process from
the passed args and LaunchOptions. It bascally does the same thing as
LaunchApp() for Linux, but it divides the procedure to two parts,
- the 1st part forking a new process, and
- the 2nd part initializing FDs, ENV, and message loops.
Going two parts gives fork servers a chance to clean new processes
before the initialization and running WEB content. For example, to
clean sensitive data from memory.
Depends on D46879
Differential Revision: https://phabricator.services.mozilla.com/D46880
--HG--
extra : moz-landing-system : lando
With a fork server, the parameters to fork a new content process are
passed through a socket. This patch does following tasks to adapt
sandbox to work with a fork server,
- passing a FD of a chroot server,
- passing flags of SandboxFork, and
- setting LaunchOptions and its fork_delegate field at a fork server.
Depends on D46878
Differential Revision: https://phabricator.services.mozilla.com/D46879
--HG--
extra : moz-landing-system : lando
I messed up and deleted my own fork once my PR was merged, given the owner said
they would do a release.
Differential Revision: https://phabricator.services.mozilla.com/D55894
--HG--
extra : moz-landing-system : lando
Jan de Mooij
Christian Holler
Miko Mynttinen
Jamie Nicol
Julian Descottes
Mihai Alexandru Michis
Michael Ratcliffe
Masatoshi Kimura
Emilio Cobos Álvarez
Tarek Ziadé
Timothy Nikkel
Daisuke Akatsuka
Mike Hommey
Asumu Takikawa
Simon Giesecke
Marco Bonardo
Botond Ballo
Dave Townsend
Boris Zbarsky
Logan Smyth
Benjamin Bouvier
Benjamin Bouvier
Kris Maglione
Perry Jiang
Thinker Li
Bert Peers