This renames a couple of functions to hopefully make their intent clearer add adds comments and assertions.
Differential Revision: https://phabricator.services.mozilla.com/D44014
--HG--
extra : moz-landing-system : lando
There's a lot of code and this path is slow enough that a non-inlined call isn't
going to be an issue.
Differential Revision: https://phabricator.services.mozilla.com/D43583
--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
We now use real NOPs on all platforms. On x86/x64 this used to be a CMP
instruction and on ARM64 this involved an unconditional LDR with some
other instructions.
Depends on D43413
Differential Revision: https://phabricator.services.mozilla.com/D43414
--HG--
extra : moz-landing-system : lando
This affects the following platforms:
* x64: use a RIP-relative LEA instead of an immediate MOV. This saves a few
hundred bytes total and seems to be a little bit faster on interpreter
micro-benchmarks.
* arm64: use ADR instead of LDR. Seems to be a measurable speedup running
Speedometer on Pixel 2 with the JITs disabled.
Differential Revision: https://phabricator.services.mozilla.com/D43398
--HG--
extra : moz-landing-system : lando
The closedOverBinding set uses the SystemAllocPolicy so we must manually
raise OOM exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D43650
--HG--
extra : moz-landing-system : lando
We only recurse into js/src/rust when jsrust is built, which it may not
be in Gecko builds. But cranelift, which may be enabled either way,
needs the extra-bindgen-flags file.
Differential Revision: https://phabricator.services.mozilla.com/D43699
--HG--
extra : moz-landing-system : lando
The closedOverBinding set uses the SystemAllocPolicy so we must manually
raise OOM exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D43650
--HG--
extra : moz-landing-system : lando
Pages that use 'new Function' heavily create a lot of ScriptSource
objects and waste memory duplicating filenames. This is particularly
problematic if the filename is a data-url. Use the existing runtime
strings cache as a straightforward way to share this. The source text
already is using this cache.
For the XDR case, we expect filenames to almost always be unique so we
can eagerly allocate the owned strings without worrying.
Differential Revision: https://phabricator.services.mozilla.com/D43186
--HG--
extra : moz-landing-system : lando
Add accessors to avoid direct access to fields so storage can be changed
later.
Differential Revision: https://phabricator.services.mozilla.com/D43185
--HG--
extra : moz-landing-system : lando
Use accessors instead of directly accessing fields so that we can later
do automatic deduplication. Add setters that can be passed owned strings
when they are available.
Replace the XDRState::codeCString mechanism entirely. First restrict
string lengths to JSString::MAX_LENGTH as a reasonable upper bound.
Introduce XDRState::codeCharsZ to generate owned strings while decoding.
In practice we would duplicate the string anyways and this better
supports unaligned and endian-safe char16_t strings as well.
Together we do the same number of copies as before.
Differential Revision: https://phabricator.services.mozilla.com/D43184
--HG--
extra : moz-landing-system : lando
For starters, js tests require the js shell, so recursing js/src/tests
make no sense.
As for the other, it feels like it's reasonably that if one didn't
opt-in to build the js shell for Gecko builds, they are not interested
in jsapi-tests and gdb-tests either.
The default for Spidermonkey standalone build being to build the shell,
nothing changes for them.
Building jsapi-tests and gdb-tests forces to build jsrust, which can be
a drag when building Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D43537
--HG--
extra : moz-landing-system : lando
Maybe back when .cargo/config.in was added, the directory indicated for
vendored crates needed to be absolute. That is at least not the case
with the current supported versions of rust.
The current setup has a few caveats:
- .cargo/config.in has shown to become stale (it currently contains
multiple unused entries)
- non-gecko build tasks have to generate a .cargo/config on their own if
they want to use vendored crates
- in turn, non-gecko build tasks that don't, may unknowingly get their
dependencies from crates.io (see the recent attempt at moving
geckodriver builds to a separate task).
By checking in a .cargo/config file, we can alleviate the last two, but
that comes at the price of `cargo update` not wanting to act when
.cargo/config exists, because of the source replacement configuration.
But rust vendor gently generates a suitable configuration on its own, so
we can use that to generate a .cargo/config automatically. Which
addresses the first caveat of the current setup. That leaves us with
`cargo update` not working out of the box, but that just requires people
running it to manually remove .cargo/config first. Which is arguably
what rust wants you to do in the first place. It's kind of incidental
that we started with a .cargo/config.in rather than .cargo/config.
Now, while a simple .cargo/config works, that's not enough for the case
where the objdir doesn't live inside the source directory. In that case
cargo looks for the configuration from the objdir, and fails to find it.
So we still need a .cargo/config.in, which we generate with a little
trick.
Differential Revision: https://phabricator.services.mozilla.com/D43012
--HG--
rename : .cargo/config.in => .cargo/config
extra : moz-landing-system : lando
