This avoids paying a cost for animating the skeleton UI for faster startups.
Slow startups don't seem to be affected, given the data available. This is
likely due to slow startups being dominated by IO.
Differential Revision: https://phabricator.services.mozilla.com/D104118
Empty bytecode sites are typically only used for Wasm compilation. Assert this
in `MBasicBlock::NewPopN()` and document this in `BytecodeSite`.
(*) The only exception are fake OSR blocks in GVN.
Differential Revision: https://phabricator.services.mozilla.com/D103660
A `MDefinition`'s tracked bytecode site is always equal to the bytecode site
of its block. Assert this property so we can remove `MDefinition::trackedSite_`
in a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D103659
Warp compilation always has a tracked bytecode site, so instead of testing if
the bytecode site's tree is non-null, test if we're currently Warp (= not Wasm)
compiling. This should make it easier to understand this code.
Differential Revision: https://phabricator.services.mozilla.com/D103658
Part 18 ensured each definition which is attached to a block has a non-nullptr
tracked bytecode site. (This is ensured through `setTrackedSite()` which asserts
the tracked bytecode site isn't a nullptr.)
Drive-by change:
- Change `CodeGeneratorShared::encode()` to store `ins->mirRaw()` in a variable.
Differential Revision: https://phabricator.services.mozilla.com/D103657
Add a separate `MDefinition::setInstructionBlock()` method which also sets the
tracked bytecode site. `setTrackedSite()` is now only called from within
`MDefinition`, so its visibility can be changed to `private`.
With this change it's easier to see that all definitions attached to a block
also have a tracked bytecode site. We will use this property in the next parts.
Differential Revision: https://phabricator.services.mozilla.com/D103655
After part 13, `MBasicBlock::trackedSite_` is never modified outside of the
constructor. And because all call-sites pass a non-nullptr, we can assert this
and remove the nullptr check in `trackedTree()`.
Differential Revision: https://phabricator.services.mozilla.com/D103652
`MBasicBlock::pc_` is initialised with `MBasicBlock::trackedSite_`'s `pc` and
after the last part `MBasicBlock::trackedSite_` is never changed after the
constructor, so we can replace `pc_` with `trackedSite_->pc()`.
Differential Revision: https://phabricator.services.mozilla.com/D103651
The copy constructors call `MNode(const MNode&)` which copies over the
`blockAndKind_` member, so the `block` information is actually copied, too.
Differential Revision: https://phabricator.services.mozilla.com/D103648
`MToInt64` seems to allow `Int64` inputs based on the comments in
`LIRGenerator::visitToInt64()`.
Also remove `MIRType::String` from the list of non-throwing types, because
`ToBigInt(string)` can actually throw a SyntaxError. This change can't be
tested, because we currently create neither `MToBigInt` nor `MToInt64` in a
context where the input is a string and the result isn't observed.
Differential Revision: https://phabricator.services.mozilla.com/D103647
Also move `LNode` tracking under `TRACK_SNAPSHOTS`, so the compiler can more
easily optimise this code away when `TRACK_SNAPSHOTS` isn't set.
Differential Revision: https://phabricator.services.mozilla.com/D103637
"mozilla/Attributes.h" was previously only included for `MOZ_MUST_USE`, so we no
longer need the include after switching to use `[[nodiscard]]`.
Differential Revision: https://phabricator.services.mozilla.com/D103669
When we change the namespace, we discard all cached resources and their
associated keys from the WebRender cache. As such if any transaction
comes in with the old namespace ID, we can safefully discard the entire
update, since we will need to recreate any that we are using anyways.
This patch also adds new asserts to ensure we never get old namespace
IDs for individual keys in a valid resource update. This should never
happen in practice.
Differential Revision: https://phabricator.services.mozilla.com/D104236
On Windows, when `moz-phab` is installed, two "executable" files are
created:
* moz-phab.exe
* moz-phab-script.py
Our `moz-phab.exe` detection was choking on `moz-phab-script.py` and was
unsure which of the two to use.
Differential Revision: https://phabricator.services.mozilla.com/D103834
This commit removes the expiring probes:
* wasm.compile_time_baseline_us
* wasm.compile_time_cranelift_us
* wasm.compile_time_ion_us
* js.run_time_us
Execution runtime is still measured in the JS interpreter for still
active probes.
Differential Revision: https://phabricator.services.mozilla.com/D104143
The baseURI is a moz-extension: URI, which does not support being loaded
synchronously from a content process, as framescripts are.
This patch does not attempt to prohibit future synchronous uses of
moz-extension: URIs, as that is outside of the scope of this issue, but we
should likely do so in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D104081
Streams serialized with the default nsIInputStream serializer will be serialized
with delayedStart, meaning that when sent from the parent process to the content
process it will be serialized as a RemoteLazyInputStream.
In the specific case of SendOpenStream this causes issues, as the content
process code depends on the synchronous nature of nsIFileInputStream to allow it
to be wrapped in a SnappyUncompressInputStream, which requires a sync stream.
Relying on this property is not generally correct and only works because we know
only nsFileInputStream will be sent by the parent process. Other types of sync
streams may be received as async if they are sufficiently large, such as
nsStringInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D103227
SetData will check that `mStartedReading` has not been set yet to ensure the
stream is in a non-partially-read state. This can lead to assertion failures
when sending a stream not seeked to the beginning over IPC.
Differential Revision: https://phabricator.services.mozilla.com/D103226
Previously if `Clone()` was called on a closed nsPipeInputStream, it could cause
crashes due to the already-closed nsPipeInputStream being added to mInputList,
violating internal nsPipe invariants. Skipping adding the stream to that list
should avoid this edge-case, as the pipe is already closed.
Differential Revision: https://phabricator.services.mozilla.com/D101807
nsMIMEInputStream has a requirement that the inner nsIInputStream object
implement nsISeekableStream, which is usually enforced by the SetData method.
This check was bypassed by the Deserialize method, which unfortunately meant
that non-seekable IPC payloads could end up within a nsMIMEInputStream when sent
from another process (e.g. due to large nsStringStreams being serialized as
nsPipes over IPC).
This patch uses the SeekableStreamWrapper introduced in the previous patch to
wrap the inner stream when deserializing nsMIMEInputStream, avoiding the
previously mentioned issue.
Differential Revision: https://phabricator.services.mozilla.com/D101806
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
The current set of cases where a nsIInputStream is directly serialized over IPC
is fairly limited, and includes cases where the IPDL struct may be directly
stored within a content process, having the nsIInputStream left unused.
By switching this serialization to DelayedStart, we can avoid performing
unnecessary streaming copies of IPC data when sending postdata streams related
to session history and document navigation, while also avoiding issues like this
coming up again due to delayed start being the default.
Differential Revision: https://phabricator.services.mozilla.com/D101804
When aDelayedStart is specified, if the created IPCStream contains an internal
IPC stream actor, an actor is used under the hood to send raw data between
processes when needed. This is usually done to reduce overhead in cases where
the target process may not use the nsIInputStream immediately, if at all.
By switching to using RemoteLazyInputStream when sending DelayedStart actors
from parent to content, the amount of data sent in the initial payload is
reduced even further, and the stream is optimized to allow sending it back to
the parent process without streaming the data through the content process again.
Normal delayed start streams are still used when sending payloads from other
processes, as RemoteLazyInputStream is only supported for nsIInputStreams
originating in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D101803
Previously, we would apply the InputStreamLengthWrapper before
DelayedStartInputStream, which meant that a stream serialized with aDelayedStart
would not correctly implement nsIInputStreamLength. By inverting the order of
these wrappers, the nsIInputStreamLength implementation is visible, without
impacting the functionality of the DelayedStartInputStream wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D101802
Sylvestre Ledru
Doug Thayer
Bogdan Tara
André Bargull
harry
Andrew Osmond
Mitchell Hentges
Brad Werth
Miko Mynttinen
Andrei Oprea
Simon Giesecke
Ryan Hunt
yulia
Nika Layzell