Bug 1458339 is looking into sharing the self-hosted code parsed by parent process to all content processes.

As the initialization of the JS Runtime happens before the event loop, which handles IPC requests, we have to rely on command line arguments and file handles. This is similar to how preferences are shared.

This change adds the ground work to share content provided by the JS engine of
the Parent process to initialize the JS engine of other threads and Content
processes.

The singleton class xpc::SelfHostedShmem is used to wrap the logic behind
holding the memory. The memory is initialized with InitFromParent or
InitFromChild. The memory is accessible using either the Content or
Handle.

The shared memory is transfered through the command line using
mozilla::ipc::ExportSharedJSInit and read using
mozilla::ipc::ImportSharedJSInit functions. The command line is used, as we
need the shared memory to be avilable for the JS engine initialization. The
command line is composed of a single command named -jsInit which is followed
by the handle (on Windows) and the length of the shared content.

The memory associated with the shared memory is cleared in ShutdownXPCOM after
closing all threads, and shuting down the JS engine. This is necessary as we
expect the JS engine to borrow content from the shared memory.

For the moment, I will flag this bug as leave-open as Part 2 is not ready to land due to geckoview unit test failures which are doing a timeout for reasons which are too obscure for me at the moment. Later, I might move the part 2 to follow-up bug to avoid keeping this one opened.

Comment on attachment 9219896 [details]
Bug 1698045 part 2 - Use shared memory for JS initialization on Android.

Revision D114126 was moved to bug 1710884. Setting attachment 9219896 [details] to obsolete.

https://hg.mozilla.org/mozilla-central/rev/08bc1462b932