1817011 - Use a static lookup table for IPDL message flags rather than storing details in IPDL headers

Status: NEW

(Core :: IPC, enhancement, P2)

Description

[Nika Layzell [:nika] (ni? for response)]

Currently we store a bunch of properties about IPDL messages in the message header for that message, even though it is constant for every message of the type. These messages are then constructed by specialized Msg_Foo() constructor messages defined from the IPDL generated code.

mozilla::UniquePtr<IPC::Message>
Msg_AddCertException(int32_t routingId)
{
    return IPC::Message::IPDLMessage(routingId, Msg_AddCertException__ID, 0, IPC::Message::HeaderFlags(IPC::Message::NOT_NESTED, IPC::Message::NORMAL_PRIORITY, IPC::Message::COMPRESSION_NONE, IPC::Message::EAGER_SEND, IPC::Message::NOT_CONSTRUCTOR, IPC::Message::ASYNC, IPC::Message::NOT_REPLY));
}

https://searchfox.org/mozilla-central/source/__GENERATED__/__linux64__/ipc/ipdl/PContent.cpp#1588-1592 (not versioned, so will probably be different when you click)

We should consider putting metadata about IPC messages instead in a table which can be efficiently looked up by msgid so that we don't need to dynamically store it in the IPDL header. We could also make it more efficient to look up values like message names that way, rather than the existing giant switch statement.

As a rough design, it may make sense to take advantage of the layout of IPDL message IDs, which use the high 16 bits for a protocol ID and the low 16 bits for a message ID within that protocol. Each protocol would have a table for the messages in that protocol, and we'd store spans for these per-protocol tables in another lookup table, which could be indexed into with the high 16 bits.