FirstStartup provides an optional mechanism to run synchronous services
before the UI appears. This is intended to be called as a post-install
action from an installer, such as the Windows Stub Installer, to allow
for downloading critical data and performance tuning before the first
run of a new Firefox install.
Differential Revision: https://phabricator.services.mozilla.com/D43364
--HG--
extra : moz-landing-system : lando
The test for procinfo doesn't check if the process type is
reasonable. With Fission, this test now asserts, so add a failure
annotation. I'll fix it up for Fission in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D44214
--HG--
extra : moz-landing-system : lando
Right now, the type ends up being uninitialized if the type doesn't
match, in the GeckoProcessType_Content case.
Differential Revision: https://phabricator.services.mozilla.com/D44213
--HG--
extra : moz-landing-system : lando
ProcType gets turned into WebIDLProcType, so I assume the intention is
that they are identical. I changed the definition of WebIDLProcType to
match ProcType, and added a static assert to check that they have the
same number of cases.
I also changed the coercion from a static_cast<> to an explicit switch
statement so that it will degrade more gracefully if, say, the enums
get reordered, or one enum gets a case added and removed at the same
time.
Differential Revision: https://phabricator.services.mozilla.com/D44212
--HG--
extra : moz-landing-system : lando
There is also a mozilla::ProcType, which makes things
confusing. dom::ProcType seems to be used only for passing values to
JS via WebIDL, so I put WebIDL in the name.
Differential Revision: https://phabricator.services.mozilla.com/D44211
--HG--
extra : moz-landing-system : lando
This commit extends the jit-test runner to support
'skip-variant-if: $FLAG, $COND', and uses this to not run
'--wasm-disable-huge-memory' tests when the platform doesn't support huge
memory.
Differential Revision: https://phabricator.services.mozilla.com/D43670
--HG--
extra : moz-landing-system : lando
We can't deserialize code that doesn't contain bounds checks if we have
dynamically switched to not using huge memory. This commit uses BuildID to
invalidate cached code correctly.
Differential Revision: https://phabricator.services.mozilla.com/D41870
--HG--
extra : moz-landing-system : lando
This commit modifies WasmMemoryObject, ArrayBufferObject,
SharedArrayBufferObject to support conditionally using huge memory based on the
global flag.
The memory logic is fairly involved and entangled, making this change a bit
tricky.
The following changes were made:
* Stopped conditionally compiling huge memory constants and prefixed them with `Huge`
* Stopped conditionally compiling `ExtendBufferMapping` and `wasmMovingGrowToSize`
* Renamed `CreateBuffer` to `CreateSpecificWasmBuffer`
* For clarity
* Moved maxSize clamping into `CreateSpecificWasmBuffer`
* Lets us keep one callsite to `wasm::IsHugeMemoryEnabled` during memory creation
* Moved mappedSize computation out of `RawbufT::Allocate` to `CreateSpecificWasmBuffer`
* Lets us keep one callsite to `wasm::IsHugeMemoryEnabled` during memory creation
* Moved `boundsCheckLimit` computation from `ArrayBufferObjectMaybeShared` to `WasmMemoryObject`
* Lets WasmMemoryObject be responsible for knowing whether it is 'huge' or not
* Added method to determine if a `WasmMemoryObject` is huge or not
* Lets use know whether we support `movingGrow` or have a `boundsCheckLimit`
* Refactored `WasmMemoryObject::grow` to have one callsite to `wasmMovingGrowToSize`
* For clarity
* Added release assert in `Module::instantiateMemory`
* Ensures we have a huge memory or bounds checks if needed
Differential Revision: https://phabricator.services.mozilla.com/D41869
--HG--
extra : moz-landing-system : lando
This commit allows us to conditionally compile bounds checks based on runtime
support for huge memory.
New flags to CompileArgs and CompilerEnvironment are added for whether we are
using huge memory or not, and computed based on the global flag.
Differential Revision: https://phabricator.services.mozilla.com/D41868
--HG--
extra : moz-landing-system : lando
To highlight that WASM_HUGE_MEMORY doesn't imply we are using huge memory, this
commit renames the #define.
Most usages of WASM_HUGE_MEMORY are not updated, as they will be removed in
later commits.
Differential Revision: https://phabricator.services.mozilla.com/D41867
--HG--
extra : moz-landing-system : lando
This commit is the boilerplate for making WASM_HUGE_MEMORY a runtime decision.
Because WasmModule's can be passed across threads with `postMessage`, we need
to make this decision once per process. The support for this kind of flag seems
ad-hoc, so I stubbed in a global flag in WasmProcess.
A new 'javascript.options.wasm_disable_huge_memory' pref and
'--disable-wasm-huge-memory' JS shell flag are added. These have no effect if
the current platform doesn't support huge memory.
Tests and fuzzing flags are modified to also test with these new flags.
Differential Revision: https://phabricator.services.mozilla.com/D41866
--HG--
extra : moz-landing-system : lando
The only observed change needed to get bounds checking working on ARM64 was to
implement `wasmBoundsCheck` in MacroAssembler-arm64.
ARM64 doesn't support predicated instructions like ARM32, so to support spectre
mitigations `wasmBoundsCheck` emits a 'csel' instruction. I'm not familiar with
how ARM performs speculative execution or how spidermonkey mitigates it, so this
was only a guess.
Differential Revision: https://phabricator.services.mozilla.com/D41864
--HG--
extra : moz-landing-system : lando
x86_64 can re-use MacroAssembler-x86-shared for its wasmBoundsCheck, and so it
doesn't require any new assembler code.
It does require a small baseline compiler change to ensure that TlsData is
loaded if we are going to do a bounds check.
I tested this commit with a x64 try run and manually disabling WASM_HUGE_MEMORY.
Differential Revision: https://phabricator.services.mozilla.com/D41863
--HG--
extra : moz-landing-system : lando
Major changes:
- add new directory under `taskcluster/docker` named `linux-test` that will supersede `desktop1604-test` when the appropriate time comes
- add new job to support building this docker image in `kind.yml`
- create a setup script similar to `ubuntu1604-test-system-setup.sh` tailored to debian 10
- modify `test-linux.sh` to support switching based on detected distribution; this is important due to differences in how pulseaudio is handled
Minor changes:
- modify logic in the mochitest harness in order to support gstreamer0.1, 0.10 and 1.0 notations (varies slightly from ubuntu1604)
Goal:
- this patch will place all the necessary piping to enable debian 10 when needed
- with the required debian 10 files and scripts recorded in tree, it is easier to have other developers quickly enable debian 10 to run tests on try
Differential Revision: https://phabricator.services.mozilla.com/D42597
--HG--
extra : moz-landing-system : lando
DONTBUILD because this is a comment-only change.
Per bug 1481951 comment 6, it seems our behavior was in fact correct even when
the comment was added, and this "// XXX" comment was just due to a
misunderstanding in what was going on in the testcase.
Differential Revision: https://phabricator.services.mozilla.com/D44229
--HG--
extra : moz-landing-system : lando
It got added in bug 1533863 for the new about:config page (bug 1493439) which is currently on enabled in Nightly (bug 1532703).
Differential Revision: https://phabricator.services.mozilla.com/D44192
--HG--
extra : moz-landing-system : lando
The current code only adds the directory if `LD_LIBRARY_PATH` is not
already set. We want to always add it so that host binaries--which will
be linked against whatever libraries the compiler in use provides--can
run correctly.
Differential Revision: https://phabricator.services.mozilla.com/D44172
--HG--
extra : moz-landing-system : lando