And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
Never store names in Message. One can get string names from
Message::name() or use IPC::StringFromIPCMessageType() when only
message id is available.
MozReview-Commit-ID: 15ksx6SE90c
--HG--
extra : rebase_source : 1a041dc365b7f42edd540d8c7a4dfd8912e48921
xpcshell can sometimes create and then almost immediately kill the GPU process. This can
cause the connection state of GPUParent's message channel to be in error or closed
when it attempts to send its build ID. In this case we should ignore the request
because the process will soon close.
MozReview-Commit-ID: EAupU844iFo
--HG--
extra : histedit_source : df05a01df5ad095b4e3c91e0e038d4e145da5f9d
The current IPC::Message constructor takes a large number of arguments,
three of which--the nesting level, the priority, and the
compression--are almost always constant by virtue of the vast majority
of Message construction being done by auto-generated IPDL code. But
then we take these constant values into the Message constructor, we
check them for various values, and then based on those values, we
perform a bunch of bitfield operations to store flags based on those
values. This is wasted work.
Furthermore, for replies to IPDL messages, we'll construct a Message
object, and then call mutating setters on the Message object that will
perform even more bitfield manipulations. Again, these operations are
performing tasks at runtime that are the same every single time, and use
information we already have at compile time.
The impact of these extra operations is not large, maybe 15-30K of extra
code, depending on platform. Nonetheless, we can easily make them go
away, and make everything cleaner to boot.
This patch adds a HeaderFlags class that encapsulates all the knowledge
about the various kinds of flags Message needs to know about. We can
construct HeaderFlags objects with strongly-typed enum arguments for the
various kinds of flags, and the compiler can take care of folding all of
those flags together into a constant when possible (and it is possible
for all the IPDL-generated code that instantiates Messages). The upshot
is that we do no unnecessary work in the Message constructor itself. We
can also remove various mutating operations on Message, as those
operations were only there to support post-constructor flag twiddling,
which is no longer necessary.
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
The lifetime of async IPDL returned promise may be longer than its actor.
That is, the handler (receiver) may have not resolve/reject the promise when the actor
is destroyed. In this case, we have to reject all the pending promises before
ActorDestroy() is called on the "sender" side.
Besides, the handler (receiver) can reject with reason "ActorDestroyed" to silently
cancel the promise without trying to reply to the remote actor which may
have died. The sender-side promise is responsible for rejecting the pending promises,
which will be done in MessageChannel::RejectPendingPromisesForActor().
MozReview-Commit-ID: 4XjmquZzDBO
--HG--
extra : rebase_source : 48539e35e4587e09be1d66497b1ea32d1a95ee9a
The wrapper should have the same liftime as the underlying
MessageLoop. This patch use the MessageLoop's DestructionObserver to
manage the lifetime of the wrapper.
MozReview-Commit-ID: 44ps4TKl3yQ
The wrapper should have the same liftime as the underlying
MessageLoop. This patch use the MessageLoop's DestructionObserver to
manage the lifetime of the wrapper.
MozReview-Commit-ID: 44ps4TKl3yQ
The new telemetry tag is for probing the best IPC message pre-allocate size to avoid
realloc overhead. We only count those message size which is greater than 4096.
This tag integrates IPC_MESSAGE_SIZE and MESSAGE_MANAGER_MESSAGE_SIZE2 which
have both expired.
MozReview-Commit-ID: GjvuidGJ7pz
--HG--
extra : rebase_source : 1da13b3f2b5b042d0445abd6051993e2fb317f93
In order to avoid a busy wait where we defer and then immediately un-defer a message,
we need to ensure that we only un-defer a message if it's actually ready to be processed.
This patch uses the same condition in MaybeUndeferIncall as we use in
DispatchInterruptMessage.
MozReview-Commit-ID: L2xZfSO0Yrk
This patch implements async returns for IPDL using MozPromises. There
are following changes:
* Initialize AbstractThreads for MessageLoops
* Record promises and their reject functions
* When async message returns, call their resolve functions
* When send error or channel close, call their reject functions
* Implement "unresolved-ipc-promises" count for about:memory
* Test cases
See bug attachment for generated code from test cases
MozReview-Commit-ID: 7xmg8gwDGaW
--HG--
rename : ipc/ipdl/test/ipdl/error/AsyncReturn.ipdl => ipc/ipdl/test/ipdl/ok/AsyncReturn.ipdl
extra : rebase_source : 9a5821d6c0e5f7152b8152a17a409b94e8258dc3
