Generalize the SIMD wormhole to both x86 and x64, and both baseline
and Ion, so that we can start experimenting with it on a broader
scale.
Change the config so that the feature will ride the trains,
preffed-off by default (the current setting). The pref disappears
from view in late betas, though the feature remains; it can be
requested by another means (later patch) from privileged content only.
Differential Revision: https://phabricator.services.mozilla.com/D101709
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D100412
For enumerateNames on Xrays, throw an OOM exception upfront. This matches what we do
inside the JS engine when enumerating large typed arrays.
Differential Revision: https://phabricator.services.mozilla.com/D103902
This has been on Nightly for almost a year and I don't think we've
seen any breakage, so I think it is time to let it ride the trains.
Differential Revision: https://phabricator.services.mozilla.com/D104555
This makes it much easier to determine which modules and components are loaded
in which processes now that they no longer each have their own compartments.
Differential Revision: https://phabricator.services.mozilla.com/D99717
This commit removes the expiring probes:
* wasm.compile_time_baseline_us
* wasm.compile_time_cranelift_us
* wasm.compile_time_ion_us
* js.run_time_us
Execution runtime is still measured in the JS interpreter for still
active probes.
Differential Revision: https://phabricator.services.mozilla.com/D104143
The pref is only checked on startup and sets a process-wide flag, so that we
don't have to worry about the value changing from under us.
Differential Revision: https://phabricator.services.mozilla.com/D102911
The pref is only checked on startup and sets a process-wide flag, so that we
don't have to worry about the value changing from under us.
Differential Revision: https://phabricator.services.mozilla.com/D102911
The JS CompileOptions used to load cache entries must be consistent with
eachother to avoid subtle and serious bugs. This adds additional checks and
makes more consistent use of `FillCompileOptionsForCachedScript`.
This patch is a refactoring and should not change any behaviour.
Depends on D103515
Differential Revision: https://phabricator.services.mozilla.com/D103516
This allows to filter chrome manifest registration by the current
background task(s, in the future). Filtration behaves just like
filtering by "application":
* filter with `backgroundtask=` means disable for all background
tasks, since no background task will match ""
* filter with `backgroundtask!=` means enable for all background task,
since every background task will not match ""
Differential Revision: https://phabricator.services.mozilla.com/D96482
Implement manifest v3 CSP that is compatible with the current chrome implementation.
Support for content_security_policy.isolated_world (a.k.a. content_security_policy.content_scripts)
has been removed for consistency with
345390adf6%5E%21/
Differential Revision: https://phabricator.services.mozilla.com/D100573
Warp doesn't use this and there's a lot of complexity to support recompiling
an IonScript while continuing to use the current one.
It might make sense to add a similar hot tier to Warp at some point, but because
Warp uses trial inlining the implementation would likely be pretty different:
we could invalidate, flag the JitScript as supporting different inlining thresholds,
and go back to Baseline to gather information.
Differential Revision: https://phabricator.services.mozilla.com/D101457
This makes it much easier to determine which modules and components are loaded
in which processes now that they no longer each have their own compartments.
Differential Revision: https://phabricator.services.mozilla.com/D99717
XRE_XPCShellMain is called from either nsBrowserApp.cpp's main (Firefox app) and xpcshell.cpp's main (XPCShell stand-alone app).
Since bug 1673623, XRE_XPCShellMain calls profiler_init and profiler_shutdown, as needed by some other code.
Unfortunately nsBrowserApp.cpp's main already calls profiler_init, the new calls are nested, which is not allowed and triggers an assertion when running `firefox -xpcshell`.
So the calls to profiler_init/shutdown are now moved out of XRE_XPCShellMain, and up into xpcshell.cpp's main; this way the Base Profiler will be properly initialized&shutdown once in both the Firefox and XPCShell apps.
Differential Revision: https://phabricator.services.mozilla.com/D100754
Introduce a mechanism for experimenting with unary and binary SIMD
instructions (x64 + ion only, nightly only, and behind flags).
Basically this is useful for performance experiments.
A specific pattern of the first 15 bytes of the mask of the shuffle
opcode is recognized as a trigger; the last byte has the opcode 0..31.
For unary operations the two input values should be the same; the lhs
will always be chosen. The pattern is recognized during lowering and
translated to specific machine instructions.
This mechanism is preferable to custom opcodes because it allows
existing tools (emscripten/llvm/binaryen/linkers) to be used without
change.
To trigger this, use --wasm-compiler=ion --wasm-simd-wormhole in the
shell or set javascript.options.wasm_baselinejit=false and
javascript.options.wasm_simd_wormhole=true in about:config.
This patch is mostly infrastructure but also introduces three
experimental opcodes: one to test for the presence and operation of
the wormhole, one to invoke the Intel PMADDUBSW instruction, and one
to invoke the Intel PMADDWD instruction.
Differential Revision: https://phabricator.services.mozilla.com/D94101
Introduce a mechanism for experimenting with unary and binary SIMD
instructions (x64 + ion only, nightly only, and behind flags).
Basically this is useful for performance experiments.
A specific pattern of the first 15 bytes of the mask of the shuffle
opcode is recognized as a trigger; the last byte has the opcode 0..31.
For unary operations the two input values should be the same; the lhs
will always be chosen. The pattern is recognized during lowering and
translated to specific machine instructions.
This mechanism is preferable to custom opcodes because it allows
existing tools (emscripten/llvm/binaryen/linkers) to be used without
change.
To trigger this, use --wasm-compiler=ion --wasm-simd-wormhole in the
shell or set javascript.options.wasm_baselinejit=false and
javascript.options.wasm_simd_wormhole=true in about:config.
This patch is mostly infrastructure but also introduces three
experimental opcodes: one to test for the presence and operation of
the wormhole, one to invoke the Intel PMADDUBSW instruction, and one
to invoke the Intel PMADDWD instruction.
Differential Revision: https://phabricator.services.mozilla.com/D94101
Covers adding the new JS global `GleanPings` for JS, the new structs for C++ at
mozilla::glean_pings, ping-id and string-table-index codegen, the usual
boilerplate for JS and C++ stuff, and tests.
Unresolved:
* What happens if we call this on a non-parent process?
(This isn't a supported mode of operation)
Differential Revision: https://phabricator.services.mozilla.com/D98671
Headers we want our consumers to use remain in mozilla/glean,
but scaffolding now lives in mozilla/glean/bindings.
This will allow me to have a binding for the GleanPings global in GleanPings.h
AS WELL AS a GleanPings.h which is the C++ consumer API for custom pings.
Differential Revision: https://phabricator.services.mozilla.com/D98670
Add `mWaitingForDecode` to indicate that main-thread is blocked on the
Monitor and should be woken. This avoids generating some of the unused
Runnables. Also ensure `mFinishDecodeRunnablePending` is only accessed while
holding the lock.
Depends on D99403
Differential Revision: https://phabricator.services.mozilla.com/D99404
The `mToken` is used across threads without full locking so it must be marked
as atomic. At the same time, we can use `exchange` operations to read or
write outside of the mMonitor lock.
Depends on D99402
Differential Revision: https://phabricator.services.mozilla.com/D99403
Be consistent about always calling `MaybeFinishOffThreadDecode` without
holding the lock to simplify code. This lets us remove a TSAN deadlock
exception.
Differential Revision: https://phabricator.services.mozilla.com/D99402