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
We need to have the label in place before placing the marker and
capturing the accompanying stack to be able to identify the loaded JS.
Differential Revision: https://phabricator.services.mozilla.com/D98094
ObjectGroup::finalize is now an empty function so define it in the header.
The objectGroupsMallocHeap memory reporter can also be removed.
Differential Revision: https://phabricator.services.mozilla.com/D97292
This patch makes cranelift and ion exclusive of each other: enabling
cranelift on a platform will effectively disable Ion on that platform.
Specifically there's a change at the pref/switch level that does not
go terribly deep:
- the new about:config option is javascript.options.wasm_optimizingjit,
the old wasm_cranelift and wasm_ionjit are no more
- new values of X in --wasm-compiler=X in the js shell are 'optimizing'
and 'baseline+optimizing', the old values 'cranelift', 'ion',
'baseline+ion' and 'baseline+optimizing' are still accepted but only
when ion or cranelift is available
- we keep the separate prefs internally in the code for ion and cranelift
but if ENABLE_WASM_CRANELIFT is defined then we never set the ion
pref to true, and if it is not defined then we never set the cranelift
pref to true
The trickiest changes are in testWasm.cpp and in the JIT compiler option
processing in jsapi.cpp.
People who will suffer as a result of this are those who are working
on ports of cranelift to new platforms in Firefox. As of now we have
no such work going on.
In the longer term the exclusive-or situation can be alleviated by a
switch that lets cranelift override ion when cranelift is present and
the switch is on. Patches welcome.
Differential Revision: https://phabricator.services.mozilla.com/D96059
The shutdown code of BackgroundReadFiles races with BeginBackgroundRead.
This is paritally obfuscated by the usage of the initialEvent convenience
of NS_NewNamedThread, so this change also removes that in favour of explicit
dispatch. (xpcom devs want to remove the convenience anyway)
Differential Revision: https://phabricator.services.mozilla.com/D94877
- We have an assumption that SetResponseHeaders will be called before WriteSegments is called for the first time. I would like to make it more structural add add a new state BEFORE_HEADERS
- mDataReceived was never set, which is wrong.
- Almost any error that occurs during ReadResponseData is a connection error and neqo will handle it internally by closing the session. This will be read by necko as ConnectionState change event. Therefore ignore errors received from mHttp3Connection->ReadResponseData and let the ConnectionChange event close the stream.
- This also adds a test. Because the stream has received some data already the transaction will br closed with the NS_ERROR_NET_PARTIAL_TRANSFER error.
Differential Revision: https://phabricator.services.mozilla.com/D94951