The other caller of EnsureBareExitFrame is when unwinding in the exception
handler and we already call deleteDebugModeOSRInfo there.
Differential Revision: https://phabricator.services.mozilla.com/D36759
--HG--
extra : moz-landing-system : lando
This test has questionable value but this just makes it
faster by reducing iteration count.
Differential Revision: https://phabricator.services.mozilla.com/D36745
--HG--
extra : moz-landing-system : lando
Convert ThreadData to ContextData in JSContext. Removed some old GCHelperState variables that are no longer being used. Removed NativeStackQuota, which is never read. Renamed SetNativeStackQuotaAndLimit to SetNativeStackLimit, as it is never setting a NativeStackQuota.
Differential Revision: https://phabricator.services.mozilla.com/D36533
--HG--
extra : moz-landing-system : lando
Adds CheckContextLocal protected data checks and a data type to check a JSContext against the TlsContext of the thread. Objects must specify the JSContext in which they are created in to check against.
Differential Revision: https://phabricator.services.mozilla.com/D36518
--HG--
extra : moz-landing-system : lando
The sharedMemoryEnabled attribute of the module environment is not a
boolean, but a true/false enum, and must be tested through an explicit
comparison with one of the enum values.
Differential Revision: https://phabricator.services.mozilla.com/D36619
--HG--
extra : moz-landing-system : lando
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 9c7cc853a635b6e94b6c89db0bd045384b58e552
This allows using the CRANELIFT_FLAGS environment variable to control some
flags. To start with, this allows selecting the optimization level (opt_level,
which can be set to fastest/default/best as of this date) and
enabling/disabling jump tables.
Differential Revision: https://phabricator.services.mozilla.com/D36322
--HG--
extra : rebase_source : 1c61676e891efc21605e45a9f47d01c4837a7430
extra : histedit_source : 9c0fc5bd2167b4d71b390ef1e563ac8bd0c91f18
- rename the cpu.rs file to isa.rs;
- create a new function for platform-specific flags, and move x86 flags in
there;
Differential Revision: https://phabricator.services.mozilla.com/D36321
--HG--
rename : js/src/wasm/cranelift/src/cpu.rs => js/src/wasm/cranelift/src/isa.rs
extra : rebase_source : 2611faa2084f82667e73cc264c10ba6f7c97c407
extra : histedit_source : f1db60e45ea7a3178c19153912d2c659c10f7f71
This introduces a bindings module in the cranelift bindings directory, to make
the roles of different files clearer:
- bindings/low_level.rs (formerly known as baldrapi.rs) contains all the
bindings automatically generated by bindgen.
- bindings/mod.rs (formerly known as baldrdash.rs) contains all the high-level
bindings, to be used by the rest of baldrdash.
Some code has been moved to match the roles more consistently; in particular,
nothing in bindings/low_level should be directly used from outer the bindings
directory.
Rustfmt has been run too, which explains a few unrelated changes.
Differential Revision: https://phabricator.services.mozilla.com/D36319
--HG--
rename : js/src/wasm/cranelift/src/baldrapi.rs => js/src/wasm/cranelift/src/bindings/low_level.rs
rename : js/src/wasm/cranelift/src/baldrdash.rs => js/src/wasm/cranelift/src/bindings/mod.rs
extra : rebase_source : b6a111cb9f8909e7872aa43452228194d81f79cd
extra : histedit_source : c774c2c4ab98e24aca637451bb0d1fd03d0b94f3
WebRender being on or off doesn't affect the JIT code, so the option is
not really useful in this harness. However, it is a downstream harness that
we'll be passing this flag to so for consistency we have it accept the
flag and silently eat it.
Differential Revision: https://phabricator.services.mozilla.com/D35865
--HG--
extra : moz-landing-system : lando
The nursery isn't exactly swept, but it is evicted. Name this function to
make it match its context better.
Differential Revision: https://phabricator.services.mozilla.com/D36316
--HG--
extra : moz-landing-system : lando
