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
mov byte ptr support was added in bug 1382251 but did not properly count the instruction size. It was missing the 1-byte operand, which causes the rest of the trampoline to be garbage.
Differential Revision: https://phabricator.services.mozilla.com/D55744
--HG--
extra : moz-landing-system : lando
This behavior is consistent with calling MessagePort.postMessage when the
entangled port is null.
Differential Revision: https://phabricator.services.mozilla.com/D55849
--HG--
extra : moz-landing-system : lando
SetWindowLong*/SetWindowLongPtr* was being intercepted so that we could override windowprocs in windowed plugins on Windows. We no longer support windowed plugins so these functions are never intercepted.
Differential Revision: https://phabricator.services.mozilla.com/D55536
--HG--
extra : moz-landing-system : lando
CloseHandle has a jump followed by enough `nop`s to fit a 10-byte patch but not enough to fit the default 13-byte patch when running Windows 8 or 8.1. This patch tells the interceptor to use a 10-byte patch on those OSs.
Differential Revision: https://phabricator.services.mozilla.com/D55535
--HG--
extra : moz-landing-system : lando
Also increase the min-width for password generation popups so at least en-US doesn't wrap.
Depends on D55742
Differential Revision: https://phabricator.services.mozilla.com/D55743
--HG--
extra : moz-landing-system : lando
This patch uses similar architecture of use counters of main thread for workers.
Which introduces the following format histograms for use counters of workers
USE_COUNTER2_*_DEDICATED_WORKER
USE_COUNTER2_*_SHARED_WORKER
USE_COUNTER2_*_SERVICE_WORKER
And add the following histograms used in conjunction with above use counter histograms
DEDICATED_WORKER_DESTROYED
SHARED_WORKER_DESTROYED
SERVICE_WORKER_DESTROYED
Differential Revision: https://phabricator.services.mozilla.com/D53221
--HG--
rename : dom/base/UseCounters.conf => dom/base/UseCountersWorker.conf
extra : moz-landing-system : lando