This stores slots/element ranges as object and start index rather than having
two separate representations (one used during marking, one when we yield to the
mutator during marking). It's possible that this could affect marking
performance but we'll catch that by checking the mark rate telemetry. This
should also reduce the size needed for the mark stack a little.
Differential Revision: https://phabricator.services.mozilla.com/D88723
On real hardware, when a background thread finishes compilation, it must signal
to the other executing threads that they need to reload a new version of the
code. Ideally, each executing thread would run an ISB instruction to do so. We
hereby use a system call membarrier that interrupts every other running thread,
and will cause the same effect as a local ISB would. It is heavyweight, so we
make sure to only run it in the case where we're on a background thread.
In the simulator, pending icache flushing requests were never satisfied before
this patch, when the request was emitted from a thread other than the main
thread. Similar behavior as above is emulated.
Differential Revision: https://phabricator.services.mozilla.com/D88395
This adds an OOL path to handle null/undefined => globalThis without a VM call.
IonBuilder optimizes that case based on TI and this ensures we're not a lot slower
for that.
Also give the MIR instruction an empty AliasSet so we can optimize it better in
inlined functions. We no longer have the thisValue hook mentioned in the comment.
Differential Revision: https://phabricator.services.mozilla.com/D88974
Initially the plan was to reuse TraceCacheIRStub but this patch adds the tracing
code for Warp separately because:
* CacheIR stub data in Warp contains nursery indexes. It's nice to keep that out of the IC-tracing code.
* We can use WarpGCPtr similar to other snapshotted GC pointers. It asserts GC things are not moved.
Differential Revision: https://phabricator.services.mozilla.com/D88965
Longer-term more CompileInfo fields should be moved into WarpSnapshot, we can
then dump these fields.
Depends on D88963
Differential Revision: https://phabricator.services.mozilla.com/D88964
Use TODO(post-Warp) for TODOs that can only be addressed when IonBuilder is gone.
Remove some TODOs that are no longer relevant or don't need to be addressed
short-term.
Depends on D88961
Differential Revision: https://phabricator.services.mozilla.com/D88962
Allowlisting this op in the checker is wrong because we don't want a
MagicValue to show up for JSOp::ToString in Baseline.
Depends on D88960
Differential Revision: https://phabricator.services.mozilla.com/D88961
The ones in maybeInlineIC have been addressed. The one about extra var environments
isn't really a TODO for Warp specifically.
Also change the stub data copying to just use nullptr if there's no stub data.
This is fairly common for simpler IC stubs.
Differential Revision: https://phabricator.services.mozilla.com/D88960
If useOffThreadParseGlobal option is set to false, ParseTask generates
CompilationInfo, that contains both input and stencil output,
and the main thread grabs it and instantiate it on the main thread, when
finishing the compilation.
Differential Revision: https://phabricator.services.mozilla.com/D88594
CompileGlobalScriptToStencil returns CompilationStencil in CompilationInfo as the result of compilation,
and the consumer can call InstantiateStencils to instantiate GC objects,
that can be done later and in different thread.
Differential Revision: https://phabricator.services.mozilla.com/D88592
This test fails when run with `--code-coverage` because that flag keeps the
top-level scripts of each file alive which messes with the census
expectations.
Differential Revision: https://phabricator.services.mozilla.com/D89060
We don't have to store a separate return offset for trial inlining, because the rectifier code after returning from the call is exactly the same. Post-bailout, inline frames will return into the normal non-inline code.
Differential Revision: https://phabricator.services.mozilla.com/D88694
Add a `getShared` accessor to RegExpObject to retrieve a previously assigned
`RegExpShared` object. And then replace two calls to the fallible
`RegExpObject::getShared()` method with the new accessor. This way we can
avoid calling a fallible method whose return value is ignored.
Depends on D88795
Differential Revision: https://phabricator.services.mozilla.com/D88796
It seems nice to also assert the array length is divisible by two, given that
the array is created entirely elsewhere.
Depends on D88794
Differential Revision: https://phabricator.services.mozilla.com/D88795
Remove unnecessary rooting and move a rooting variable outside of a loop. Sadly
we still don't have static analysis to catch this (bug 1362038).
Drive-by change:
- Add more blank lines before comments.
Depends on D88792
Differential Revision: https://phabricator.services.mozilla.com/D88793
The `skip` out-param is only read when `InterpretDollar` returns `true`, so we
can remove both assignments which are followed by `return false`.
Drive-by change:
- Move another assignment to `skip` to appear directly before `return true`, so
it's more obvious that `skip` only needs to be set on success.
- Add a blank line before a comment, per our normal style guides.
Depends on D88791
Differential Revision: https://phabricator.services.mozilla.com/D88792
These macros were used by the local irregexp copy to implement Unicode RegExps.
They have been replaced by calls to ICU.
Depends on D88789
Differential Revision: https://phabricator.services.mozilla.com/D88790
`next()` throws StopIteration when the iterator has been exhausted. Before
PEP 479, throwing StopIteration implicitly closes a generator and is not
propagated to the caller. After PEP 479, the StopIteration error is propagated
to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D88789
Unfortunately we already have MSetArrayLength so introducing MCallSetArrayLength might be confusing.
I am not sure what do instead.
Differential Revision: https://phabricator.services.mozilla.com/D88902
CacheIRCompiler using int32-or-double and MIR always using double makes it annoying
to share more code like in the previous patch. Hopefully we can align this more in
the future.
Differential Revision: https://phabricator.services.mozilla.com/D87708
GuardAndGetNumberFromBoolean is infallible, so that was renamed to BooleanToNumber.
That's consistent with BooleanToString.
Differential Revision: https://phabricator.services.mozilla.com/D87704
The patch converts the relevant prefs to use StaticPrefList and let's content JS in child processes to run longer if there
aren't mousedown/ups or keyevents or such. mousemove or wheel aren't considered as important events.
Differential Revision: https://phabricator.services.mozilla.com/D88668
This lets us include some extra flags in the MIME type that's used by the bytecode
cache. It also simplifies the XDR code a bit.
The approach is similar to Wasm's GetOptimizedEncodingBuildId.
Differential Revision: https://phabricator.services.mozilla.com/D88726
This adds the preference, JS shell option, and {ContextOptions,CompileOptions} fields,
but the value isn't read and the code always acts as it's set to true.
Differential Revision: https://phabricator.services.mozilla.com/D88922
Since the `dumpStencil` duplicates part of the BytecodeCompiler code, we must
explicitly instantiate the top-level stencil before parse is run. Also add a
test case for this.
Differential Revision: https://phabricator.services.mozilla.com/D88898
The assertion in emitLoadArgumentSlot was unnecessary. Spread calls always have an argc of 1, so `hasArgumentArray` and `!addArgc` cancel each other out in GetIndexOfArgument.
Depends on D88513
Differential Revision: https://phabricator.services.mozilla.com/D88514
CallInfo::ArgFormat::Array supports FunApplyArray (in this patch), SpreadCall (in the next patch), and eventually SpreadNew/SpreadSuperCall.
Depends on D88512
Differential Revision: https://phabricator.services.mozilla.com/D88513
Prior to the NON_PACKED flag, we had to iterate over each element of the array to verify that it was packed. It made sense to fold the argc check in with that code. Now that we are using the flag, I moved the argc check inside the call op to match other argument formats.
Differential Revision: https://phabricator.services.mozilla.com/D88510
Put the optimised marking path inside the trace hook so that we simplify
calling the trace hook from the marking code.
Differential Revision: https://phabricator.services.mozilla.com/D88632
Transpile `LoadInstanceOfObjectResult` through the existing `MInstanceOf` op.
In contrast to the CacheIR implementation, `MInstanceOf` can also handle
proxy objects in the prototype chain via a VM call, whereas the CacheIR
implementation always bails out in that case.
Depends on D88574
Differential Revision: https://phabricator.services.mozilla.com/D88575
Change `MInstanceOf` to use `MDefinition` for the prototype in preparation for
part 3. Lowering uses `useRegisterOrConstant()` to ensure we still bake in the
prototype for constant objects, which is the default in both Ion and Warp.
Drive-by change:
Remove bogus `LInstanceOfV::lhs()` and `LInstanceOfCache::lhs()` methods. The
left-hand side is a boxed operand, so it can't be accessed through `getOperand`.
Depends on D88573
Differential Revision: https://phabricator.services.mozilla.com/D88574
Use a CallVM instead of a FailurePath to match the Ion optimised path. This
change will allow part 4 to use the existing MArrayJoin call for Warp.
Differential Revision: https://phabricator.services.mozilla.com/D88564
We don't currently use this in Warp and it can cause some weirdness, especially
with lower warmup thresholds and off-thread compilation, where we start a
recompile for no good reason.
Differential Revision: https://phabricator.services.mozilla.com/D88584
We can only assert that the array length is writable for the
`handleTrue = true` case. This also requires to reintroduce the writable array
length check to the Ion IC code.
Added tests to cover multiple scenarios where the StoreDenseElementHole IC is
used.
Differential Revision: https://phabricator.services.mozilla.com/D88031
This parses BigInt property names as if they were computed, which means we don't end up neeeding to atomize
them.
This does mean that BigInt property names take a slower path on construction, meaning that it is possible
to measure a slowdown on executing the construction of a huge literal with thousands of BigInt properties.
This patch adds one bit to ParseNode.h, but does not change the overall size of parse nodes, as it fits
into padding around pre-existing bitfields.
Differential Revision: https://phabricator.services.mozilla.com/D87627
Despite looking directly at this code while adding the assertion in bug 1660553, I somehow missed that scripted calls were being attached too early. It's not a problem for Ion, because we only inline `FunCall`/`FunApply` if we're calling the jsnative, but it matters for Warp.
Differential Revision: https://phabricator.services.mozilla.com/D88463
To make CompilationInfo a result of off-thread compilation,
it should be allocated on heap.
Remove explicit rooting and add trace functions.
Differential Revision: https://phabricator.services.mozilla.com/D88338
This ensures isWasmWithJitEntry() is always true for the function, fixing a perf
cliff with ICs (function was called with native ABI instead of JIT ABI). It also
fixes an assertion failure when Warp is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D88383
Also, remove the existing uses of Result<const nsCString, nsresult> in URLPreloader
and Result<CryptoScheme, const nsCString> in SampleIterator.
Differential Revision: https://phabricator.services.mozilla.com/D88419
Firefox was crashing after toggling the Warp pref. This patch fixes it by storing
an isTypeInferenceEnabled flag in XDR similar to the pointer size.
Differential Revision: https://phabricator.services.mozilla.com/D88405
Until we have a complete system for scope shapshotting, there is still a
window for OOM to happening while computing annex-B redeclaration behaviour
within eval. Work around this by propegating the OOM to further up to caller.
Differential Revision: https://phabricator.services.mozilla.com/D88476
Now we have the following 5 public methods, and the consumer should call one of them, depending on the target:
* initForGlobal
* initForStandaloneFunction
* initForEval
* initForModule
* initFromLazy
Depends on D88216
Differential Revision: https://phabricator.services.mozilla.com/D88217
CompilationState is used from both Parser and BytecodeEmitter,
so SourceAwareCompiler should have it, and hide CompilationState from the API
consumers (except the place that directly calls Parser).
Depends on D88215
Differential Revision: https://phabricator.services.mozilla.com/D88216
The output of the compilation is input + stencil, and CompilationState is
purely the internal data.
Depends on D88213
Differential Revision: https://phabricator.services.mozilla.com/D88214
CompilationGCOutput should have different lifetime than input + stencil.
CompilationGCOutput can even be allocated in different thread than the
compilation (off-thread compilation will instantiate stencil in main thread).
Depends on D88208
Differential Revision: https://phabricator.services.mozilla.com/D88209
This patch just adds 4 structs to categolize CompilationInfo fields.
Later patches will simplify methods and consumers.
Depends on D88204
Differential Revision: https://phabricator.services.mozilla.com/D88205
ParserAtom now holds either AtomIndex that is an index into
CompilationInfo.atoms, or WellKnownAtomId that maps to cx->names() fields.
ParserAtoms in WellKnownParserAtoms holds WellKnownAtomId,
and ParserAtoms in CompilationInfo.parserAtoms holds AtomIndex.
GetWellKnownAtom relies on the struct layout of JSAtomState, to
quickly map WellKnownParserAtoms to its field.
Differential Revision: https://phabricator.services.mozilla.com/D88203
Instead, rename funcData to scriptData and reserve index 0 for top-level. In
non-function script cases, we have to explicitly reserve the ScriptStencil
because this was previously only done by the FunctionBox code.
Differential Revision: https://phabricator.services.mozilla.com/D87068
The stencil data structures no longer interact directly with the GC and
remaining tracing code can be removed. The relevant vectors in the
CompilationInfo can also be simplified as a result.
Differential Revision: https://phabricator.services.mozilla.com/D88079
This stores the slot span in the object slots error for dictionary mode
objects. Since it's possible to have dictionary mode objects without dynamic
slots, this adds sentinel ObjectSlots instances for each possible dictionary
slot span up to the maximum number of fixed slots.
Differential Revision: https://phabricator.services.mozilla.com/D87888
Again similar to the IonBuilder code but without the stack spoofing.
IonBuilder uses BytecodeIsPopped(pc) for ignoresReturnValue but the return value
of a setter is never used so we can just pass true.
Depends on D88268
Differential Revision: https://phabricator.services.mozilla.com/D88269
We can reuse most of the code in maybeCallTarget for creating a WrappedFunction
from callee/nargs/flags, so that was factored out as a helper function.
Instead of the "stack spoofing" that IonBuilder does (see ensureHasSlots call),
add initForGetterCall to CallInfo so we can set callee/thisv directly.
Depends on D88266
Differential Revision: https://phabricator.services.mozilla.com/D88267
We had different CacheIR ops for receiver-is-object and receiver-is-Value. This
patch unifies them by always using the receiver-is-Value version. This makes it
easier to transpile in Warp.
When generating CacheIR, pass and use the receiverId (Value) in a few places
instead of objId. This also lets us support non-object receivers for super.prop
There are two places where this doesn't work and boxObject is used to convert
from object-id to value-id. In the future this could be a dedicated CacheIR op
instead of a cast, but that would require BaselineInspector changes.
Differential Revision: https://phabricator.services.mozilla.com/D88264
As of bug 1660976, the in-tree Cranelift copy supports wasm atomics when compiling via the new
x64 back end. This small patch contains the SM-side changes required to allow wasm atomics to be
passed into that compilation pipeline.
Differential Revision: https://phabricator.services.mozilla.com/D88245
Previously HelperThread instances lived in the GlobalHelperThreadState vector.
This meant that resizing the vector could move the objects in memory which was
not safe. Also HelperThread members were not always initialized. I'm not sure
how this managed to work.
This changes the vector to contain pointers to HelperThreads which now won't
get moved. Also, for some reason the vector itself was a separate allocation
which was unnecessary. The patch makes this part of the main object.
I added a threads() method taking a lock reference since the thread list can
now change after initialization. Finally I simplified the thread creation
loop.
Differential Revision: https://phabricator.services.mozilla.com/D88111
This is needed since updating the function name will soon be fallible which
is not allowed in UpdateEmittedInnerFunctions. Move the name updates to the
same place that ObjectGroup updates happen which suffer the same OOM issue.
If an OOM occurs here during delazification, the next attempt at recompile
will compute the same name. Applying the name update early is not a problem
and is what the frontend previously did before stencil.
Differential Revision: https://phabricator.services.mozilla.com/D88174
Baseline call ICs can have 5 different argument formats (normal, spread, funcall, funapply-args, funapply-array). Some of these, like funcall, can be converted into a normal MCall by modifying the fields of the CallInfo. Others, like spread calls, are represented by different MIR nodes.
Inlining doesn't generate an MCall but also has to use the correct arguments. To avoid duplicating code, this patch splits out a helper function that updates CallInfo where possible, and returns an enum value to trigger special handling for more exotic cases. (When handling spread calls and funapply-array, I suspect that we will want to move the enum inside CallInfo, but I'm holding off on that until I actually try writing that code.)
Differential Revision: https://phabricator.services.mozilla.com/D87909
Previously HelperThread instances lived in the GlobalHelperThreadState vector.
This meant that resizing the vector could move the objects in memory which was
not safe. Also HelperThread members were not always initialized. I'm not sure
how this managed to work.
This changes the vector to contain pointers to HelperThreads which now won't
get moved. Also, for some reason the vector itself was a separate allocation
which was unnecessary. The patch makes this part of the main object.
I added a threads() method taking a lock reference since the thread list can
now change after initialization. Finally I simplified the thread creation
loop.
Differential Revision: https://phabricator.services.mozilla.com/D88111
If a script cannot be warp-compiled, then we do not want to do trial inlining for that script. Where possible, it seems better to mark scripts proactively, instead of undoing the trial inlining after failing to warp-compile.
Differential Revision: https://phabricator.services.mozilla.com/D87899
Fixes a regression from the refactoring in bug 1561521, where TC::Ref was previously
used as the value to represent any reference value in ValType.
Differential Revision: https://phabricator.services.mozilla.com/D88100
Normal arguments that spill on the stack are packed, but not variadic
arguments. This is handled correctly for their placement already, but
code generated on the callee side with va_list expects word-size
sign-extension, so we need to fill the entire word.
Upstreamed as https://github.com/libffi/libffi/pull/577.
Differential Revision: https://phabricator.services.mozilla.com/D87825
All the patches previously applied, except the one from bug 1279096,
are either irrelevant (as pertaining to changes to the upstream build
system we don't use anymore), were applied upstream, or the issue they
fixed were fixed differently upstream.
Two additional patches, sent upstream as
https://github.com/libffi/libffi/pull/579 and
https://github.com/libffi/libffi/pull/580, are needed to fix our build
with, respectively, mingw-clang and GCC.
Our build system is adjusted according to upstream's configure.ac
and configure.host.
Differential Revision: https://phabricator.services.mozilla.com/D87824
It never told libffi what the variadic arguments were.
Also fix the ctypes declaration of test_vector_add_va_cdecl in the unit test,
which is actually wrong, but the test still passed for some reason.
Differential Revision: https://phabricator.services.mozilla.com/D87557
Normal arguments that spill on the stack are packed, but not variadic
arguments. This is handled correctly for their placement already, but
code generated on the callee side with va_list expects word-size
sign-extension, so we need to fill the entire word.
Upstreamed as https://github.com/libffi/libffi/pull/577.
Differential Revision: https://phabricator.services.mozilla.com/D87825
All the patches previously applied, except the one from bug 1279096,
are either irrelevant (as pertaining to changes to the upstream build
system we don't use anymore), were applied upstream, or the issue they
fixed were fixed differently upstream.
Two additional patches, sent upstream as
https://github.com/libffi/libffi/pull/579 and
https://github.com/libffi/libffi/pull/580, are needed to fix our build
with, respectively, mingw-clang and GCC.
Our build system is adjusted according to upstream's configure.ac
and configure.host.
Differential Revision: https://phabricator.services.mozilla.com/D87824
`MStoreElement` with `needsHoleCheck=false` matches the Baseline implementation
of `StoreDenseElementHole`. `MStoreElementHole` handles more cases than the
Baseline (and Ion) implementation of StoreDenseElementHole`, namely it also
allows to set elements for `index > initializedLength`.
The `index > initializedLength` restriction for `StoreDenseElementHole` may be
lifted in the future when it's no longer necessary to call `noteHasDenseAdd()`
for Ion.
Differential Revision: https://phabricator.services.mozilla.com/D87563
Using `MLoadElement` with `needsHoleCheck=true` to trigger a bailout when a
hole is encountered was slightly slower than the new `MGuardElementNotHole`
instruction from this patch, even though the `MLoadElement` from a `JSOp::In`
can be merged with a subsequent `MLoadElement` from a `JSOp::GetElem`. This
sequence happens for the common pattern of `if (i in array) val = array[i]`.
The magic value check in `LGuardElementNotHole` works without unboxing the
value, so it's possible using separate instructions leads to fewer register
dependencies (when compared to merging the `MLoadElement`), which helps
speculative execution. And because the loaded value may still be in a cache,
it doesn't matter to load it repeatedly.
Differential Revision: https://phabricator.services.mozilla.com/D87562
The code generator uses a signed value and the value is implicitly coerced to
`int32_t` anyway (via `Int32Value`), so we might as well directly use `int32_t`
for that function.
Differential Revision: https://phabricator.services.mozilla.com/D87561
`StoreDenseElementHole` and `ArrayPush` are both preceded by shape guards and
are only attached when the object has a writable array length. That means the
generated code doesn't actually need to test `NONWRITABLE_ARRAY_LENGTH`,
because it's implied by the shape guard: Changing the array length to
non-writable through either `js::ArraySetLength` or `js::SetIntegrityLevel`
already changes the shape and thus invalidates the shape guard.
The same applies to the non-extensible bits, so we can assert that, too.
Drive-by change:
Remove the `thisarray->lengthIsWritable()` assertion in `tryAttachArrayPush`
because it's tested just a few lines earlier.
Differential Revision: https://phabricator.services.mozilla.com/D87560
Use Maybe<uint64_t> for the max size in three places where this is required.
Drive-by fix: Use standard printf macros for formatting, and use them correctly.
Differential Revision: https://phabricator.services.mozilla.com/D87710
It appears that the existing limit of 16 args for CacheIR was established when we first added FunApplyArray support in bug 906781 and never revisited.
Depends on D87681
Differential Revision: https://phabricator.services.mozilla.com/D87682