CodeCoverageHandler relies upon CrossProcessMutex. On Linux this is
implemented using shared memory. In bug 1658847, we used to the
profiler's "thread sleep" mechanism to resolve the signal interrupts in
posix_fallocate, which requires the profiler to be initialized. As such,
CodeCoverageHandler now needs to be initialized after.
Differential Revision: https://phabricator.services.mozilla.com/D87747
The issue was that the getHighlighter request for the about:printpreview
target never settled. It appears that the document always stays in an
unitialized readyState, which was causing trouble.
Instead of relying only on readyState, we now call isDocumentReady, which
also checks if the document is loading.
Differential Revision: https://phabricator.services.mozilla.com/D87756
This adds explicit support for esr versions. It also moves support for
parsing the `firefox --version` output in mozversion, so that geckodriver
isn't reimplementing part of the logic itself.
Differential Revision: https://phabricator.services.mozilla.com/D86346
So far in bug 1660174 (5 failures tagged on Windows 7), the shortest duration
we have observed for the 1-second timer is 999.9ms. To be on the safe side I'm
allowing durations down to 999.5ms.
Differential Revision: https://phabricator.services.mozilla.com/D87798
`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
