The only thing we needed opened actor tracking for was the ability to
clone all the actors. But now that we no longer have support for
cloning actors, we no longer need to track the actors that we've cloned,
which makes a number of things significantly simpler.
CloneOpenedToplevels, which is never called, is the only interesting
caller of CloneToplevel. And CloneToplevel, in turn, is the only
interesting caller of CloneManagees. Which means we can ditch all this
code for a decent amount of space savings, both in code and writable
static data (no more useless virtual function entries in vtables).
There's no reason to generate identical code for every kind of managed
protocol; we can have a single instance that operates on void* and cast
our way to victory. This change saves ~60K of text on x86-64 Linux.
Actor reading from IPC message is codegen'd with a lot of repeated code.
We can improve that by moving the core actor reading code out of
subclasses into IProtocolmanager. While we still need to codegen a bit
of code to cast the read actor to the proper type, the code overall is
smaller. The lone downside is that if we do encounter an error reading
the actor id out of the message, the precision of our crash messages is
reduced somewhat: we no longer have the protocol name doing the reading,
nor do we get crash report annotations, since we can't tell whether
we're in the parent or child process.
Also fix a handle leak in mozilla::ipc::AnnotateProcessInformation().
MozReview-Commit-ID: DuepDytfoD2
--HG--
extra : rebase_source : 0b0dd05a3728e64962a774a2dcc35dc7646aa4dc
We do this for the same reasons outlined in part 1: calls to
NS_RUNTIMEABORT are rather large and we generate a lot of them (~1000
left after part 1). This patch reduces .text size by ~20K on x86-64
Linux.
We don't do anything with it in terms of error reporting, we pass in 0
in the child process, and if you're in a debugger, presumably you can
figure out the other process's PID yourself.
The first step to eliminating all the generated Message subclasses the
IPDL compiler spits out is to move the functionality of their Log
methods someplace else. In addition to eliminating the need for the Log
methods, this change has the welcome effect of moving a bunch of code
that would be generated hundreds of times into a single place, which
should reduce code size a bit (debug builds only). We don't actually
remove the generation of the Log methods; that change will be done for a
future patch.
When the parent process has trouble deserializing an IPC message from the content
process, it originally killed that content process. This doesn't result in us
creating a crash report (and doing so is difficult if the FatalError is hit
off main thread). We now crash the parent process if we hit such a FatalError
in the parent process. This will hopefully give us an idea of how frequent
these FatalErrors are, since up until now we've been getting no crash data
for them.
--HG--
extra : commitid : J1E7vnGmvOa
extra : rebase_source : 66a4cfc599bc6f5ce113dd49439e247a474c48a4
extra : amend_source : 1d6f5f26455dd810c3c3ffb4b807e734c74d87a7