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
Report both failures and skipped test counts.
(Also incidentally fixes platform name reporting of fission tests.)
Differential Revision: https://phabricator.services.mozilla.com/D44074
--HG--
extra : moz-landing-system : lando
This causes the unit tests in browser/components/newtab to be run by Phabricator each time someone uploads a patch that touches those directories. Once they've run (it can often take an hour or so to do the required Linux PGO build first), they will be visible as node(newtab) in the page linked to by "Treeherder Jobs" on the main review page.
Differential Revision: https://phabricator.services.mozilla.com/D43983
--HG--
extra : moz-landing-system : lando
This removes a rather verbose warning during URI mutation. This often
happens for use cases such as attempting to clear the field. Since `Finalize`
is marked as `MOZ_MUST_USE` we can be confident that any failures that used
to be warned about are properly handled.
Differential Revision: https://phabricator.services.mozilla.com/D42384
--HG--
extra : moz-landing-system : lando
In FrameLayerBuilder::ChooseScale we hit this line https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/layout/painting/FrameLayerBuilder.cpp#6124 and aVisibleRect is empty (because every call site except for nsDisplayMasksAndClipPaths::CreateWebRenderCommands (which doesn't need to) passes empty for the size of the bounds) and so the maxScale stays at 4, and we clamp to 4 instead of something 30-50.
The call to ChooseScale in StackingContextHelper::StackingContextHelper is the only place the size of aBounds is ever looked at. And we only ever call ChooseScale if we are passed a mBoundTransform which only nsDisplayTransform does. So this change should be quite safe.
Differential Revision: https://phabricator.services.mozilla.com/D43546
--HG--
extra : moz-landing-system : lando
We have an optimization to avoid an expensive reflow from SetFullZoom, see
mSuppressResizeReflow[1].
That was done because we used to do a full synchronous reflow right after. We no
longer do that, but due to that member we also don't invalidate!
My second patch in this bug changes the behavior of that flag so that we don't
synchronously reflow, but we do invalidate. So in turn this test before the
change wasn't really testing the zoomed code-path since it was using the clean
layout from before the zoom operation.
a11y getBounds and co. don't flush layout (they probably should), but since with
my patch we dirty the frame tree, and dirty frames return bogus offsets, the
test starts failing.
Flush layout explicitly to ensure we're testing the zoomed code path.
[1]: https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/layout/base/nsPresContext.cpp#952
Differential Revision: https://phabricator.services.mozilla.com/D43952
--HG--
extra : moz-landing-system : lando
