The patch adds areanas allocated during marking into a separate set of arenas lists, which are not swept but are merged back into the main arena lists at the end of sweeping.
We do need to do some sweeping for newly allocated arenas on account of type inference data. I haven't looked too hard into why this is.
Differential Revision: https://phabricator.services.mozilla.com/D79334
These just do a Shape guard against a Shape stored in the Realm. If the guard
fails we do a callWithABI to a function that updates the shape.
Differential Revision: https://phabricator.services.mozilla.com/D79265
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One affect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
This patch bases on the work of krystalyang2 with minor bug fixes.
The patch includes several major parts,
1. mark nursery strings pointed by tenured strings as
non-deduplicatable,
2. deduplicate strings when they are moved to tenured from nursery, and
3. adjust dependent strings to correct their pointers to the base
string and external buffer after tenuring.
4. reorder store buffer processing to trace the string whole cell buffer
first, since strings traced through the whole cell buffer need to be marked
non-deduplicatable.
(Part 4 was originally phabricator D77715 but is now merged in here.)
Differential Revision: https://phabricator.services.mozilla.com/D74366
This is an adaptation of @bbouvier's patch D77228, updated to avoid
passing wasmparser types across the API boundary between SpiderMonkey
and Cranelift.
Co-authored-by: Benjamin Bouvier <benj@benj.me>
Differential Revision: https://phabricator.services.mozilla.com/D78589
The inline comment explains most of this, but essentially because we bail out
of the FrameIter loop early when we find an asyncStack, we can end up with
cases where the a Debugger eval's parent frame either hasn't been populated in
the LiveSavedFrameCache at all, or else _has_ been, but is not instantiated
in the correct realm.
This patch avoids that by no longer bailing when asyncStacks are found, and
instead traversing the whole stack still to make sure that the invariants
for the LiveSavedFrameCache are preserved properly.
Differential Revision: https://phabricator.services.mozilla.com/D76426
This bug is caused because creating a LiveSavedFrameCache::FramePtr from a
FrameIter special-cases RematerializedFrames that are also PhysicalJitFrames.
This creates a FramePtr for a CommonFrameLayout, which is reasonable, but it
conflicts with the fact that ExecuteKernel is only passed an AbstractFramePtr
which means that when we go to compare the two FramePtr values, one is a
RematerializedFrame and one is a CommonFrameLayout even though they both
refer to the same frame.
This patch uses the FrameIter construction method for all FramePtr instances
so we avoid this two-constructor approach and can be more easily sure that
all code paths can properly construct the same FramePtr.
Differential Revision: https://phabricator.services.mozilla.com/D76425
This is an adaptation of @bbouvier's patch D77228, updated to avoid
passing wasmparser types across the API boundary between SpiderMonkey
and Cranelift.
Co-authored-by: Benjamin Bouvier <benj@benj.me>
Differential Revision: https://phabricator.services.mozilla.com/D78589
The CacheIR code is just a VM call that's slightly faster than the CallNative path.
The main benefit is that this lets Warp use the optimized regexp stubs.
At some point it would be nice to call the same code stubs from CacheIR.
Differential Revision: https://phabricator.services.mozilla.com/D79041
Update existing tests to run with `SharedArrayBuffer` and `ArrayBuffer`.
Also add new tests for cases which weren't previously possible (detached
buffers and TypedArrays using inline storage).
Differential Revision: https://phabricator.services.mozilla.com/D76322
We no longer need to guard against non-shared TypedArrays when inlining
`Atomics` functions.
The `MemoryBarrierRequirement` changes for `M(Load|Store)UnboxedScalar` were
made to keep at least some users for `TypedArraySharedness`. In practice this
code won't be used anyway, because `TemporaryTypeSet::getTypedArraySharedness`
always returns `UnknownSharedness`. Also see bug 1225025.
Differential Revision: https://phabricator.services.mozilla.com/D76320
The TypedArray data extraction had to be moved from `AtomicAccess` into the
actual operation to account for the case when a TypedArray using inline data
is moved by the GC due to side-effects triggered by type conversions within
the operation. Part 4 contains tests to cover this case.
Because the TypedArray data is no longer passed to the operation, we can't use
it anymore to determine the data type from the `SharedMem<T>` parameter. Instead
pass an `ArrayOps<T>` instance to the operation, so we can determine `T` within
the lambda function. (Templated lambda functions are only available starting
with C++20!) The compiler should be able to optimise away the stack allocation
for this instance, so this won't incur any performance costs.
Differential Revision: https://phabricator.services.mozilla.com/D76319
These days, FunctionBox can be created without a JSFunction which is also
suitable for the asm.js dummyFunction case. Remove the function and pass name
and flags directly to the FunctionBox.
We set flags to INTERPRETED_NORMAL since that is only type of function
allowed at this point in the asm.js context.
Differential Revision: https://phabricator.services.mozilla.com/D78802
Avoid allocating the JSFunction / WasmModuleObject for asm.js during parsing,
but continue to generate the JS::WasmModule (which does not use GC). Add a
map to the CompilationInfo to keep track of these modules until stencils are
being instantiated.
Differential Revision: https://phabricator.services.mozilla.com/D78089
This changes the test to be much more specific.
It adds a way of making gcslice only trigger a slice during an incremental collection, without which the collection loop can loop forever.
Differential Revision: https://phabricator.services.mozilla.com/D79136
This fixes a regression from bug 1643680 because the code relied on Math.min/max
with int32 and double arguments returning an int32 when possible. Porting this
to C++ should make this less brittle.
Differential Revision: https://phabricator.services.mozilla.com/D78917
To completely remove Frame::tls we shouldn't use it in wasm stub.
So, in this patch we manually preserve WasmTlsReg in jit import exit stub and so remove using masm.loadWasmTlsRegFromFrame.
There are no any uses of WasmTlsReg in wasm stubs.
Only in masm.callABI but we are going to handle this later.
Differential Revision: https://phabricator.services.mozilla.com/D78223
Especially after bug 1622963 landed, the system `python3` executable as reported by `which` may not be compatible with the build system (because it might be Python 3.5, for one). You can configure a custom `python3` executable by setting the `PYTHON3` environment variable, but `configure` just calls directly into `python3` regardless of whatever you might have configured `$PYTHON3` to be, so we fix that here.
Also remove an explanatory comment that may have made sense 5 years ago but is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D79187
We fill in the match pairs for atom regexps using an ABI call, then use the normal jit path for everything else (checking for errors, allocating results, etc...).
I also made a drive-by fix to remove the cx argument from RegExpShared::executeAtom, since we don't need it.
Differential Revision: https://phabricator.services.mozilla.com/D79001
