Re: Intent to ship: Devirtualizing IPC method calls (bug 1512990)

2019-02-04 Thread Kris Maglione

On Mon, Feb 04, 2019 at 04:29:54PM -0500, Alex Gaynor wrote:

b) Memory -- we no longer need to emit vtables for all of these methods
(~20 KB per process)


\o/


c) Ergonomics -- implementing classes will now have control over whether
they take arguments by value or reference


\o/

Thank you :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to ship: Devirtualizing IPC method calls (bug 1512990)

2019-02-04 Thread Alex Gaynor
Hi dev.platform!

I wanted to let everyone know about some changes to how C++ IPDL actors are
implemented that are currently in the process of being landed (I expect to
land them to autoland tomorrow morning). This message will summarize these
changes, for complete details see
https://bugzilla.mozilla.org/show_bug.cgi?id=1512990.

Currently if you have an PProtocol.ipdl file like:

namespace mozilla {
namespace dom {

async protocol PProtocol {
both:

async Method(ArgType arg);

}

}
}

You'd write a C++ implementation like:

class ProtocolParent : PProtocolParent {
virtual IPCResult RecvMethod(ArgType& arg) override;
}

With the upcoming patches in bug 1512990, for new protocols/methods you'll
need to make the following changes:

1. RecvMethod will no longer be virtual/override - this also applies to
Alloc, Dealloc, and Answer methods.
2. ProtocolParent needs to friend class PProtocolParent (and the same for
the Child side).
3. ProtocolParent should be in an EXPORTS header which is the combination
of the namespace + the protocol name. So for our example, ProtocolParent's
declaration should be in mozilla/dom/ProtocolParent.h

This means in mozilla/dom/ProtocolParent.h you'll have:

class ProtocolParent : PProtocolParent {
friend class PProtocolParent;

IPCResult RecvMethod(ArgType& arg);
}

Why these changes?

These let the IPDL compiler emit direct calls, instead of virtual calls, to
all of these methods. This has three benefits:

a) Theoretically, performance -- though in practice, PGO seems to already
devirtualize these calls
b) Memory -- we no longer need to emit vtables for all of these methods
(~20 KB per process)
c) Ergonomics -- implementing classes will now have control over whether
they take arguments by value or reference

We have ported the majority of protocol implementations to this new way of
being, however some were still left unported for various reasons. You can
see them in ipc/ipdl/ipdl/direct_call.py (
https://phabricator.services.mozilla.com/differential/changeset/?ref=567592).
There we have a list of protocols/classes that still use virtual calls, and
some which merely don't comport to these naming conventions. We'd like to
burn this list down to nothing eventually, so please don't add anything to
it unless absolutely necessary!

If you have a protocol with _multiple_ implementing types that will also
work slightly differently. In that case, instead of having multiple types
which directly subclass PProtocolSide, you should define a single class
which directly inherits PProtocolSide and all of your other implementors
should subclass it. This gives you control over which methods are virtual.

If you have any questions or concerns, please don't hesitate to holler.
I'll be updating the IPDL docs on MDN to reflect these changes.

Cheers,
Alex
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform