The fact that plugin and GMP processes cannot use XPCOM is a real headache. See  for an example. We added NS_InitMinimalXPCOM for the GPU process. It seems like it would be pretty simple to do that for plugins and GMP as well. That would then allow us to rip out some Chromium code and use XPCOM for more stuff, which would be nice. I'm going to needinfo a few people to see if anyone knows of any reason why this would be a bad idea. One thing I can think of is that we would need to measure the increase in memory usage and startup time for these processes. I'm hoping it will be minimal.  https://bugzilla.mozilla.org/show_bug.cgi?id=1313200#c40
(In reply to Bill McCloskey (:billm) from comment #0) > I'm going to needinfo a few people to see if anyone knows of any reason why > this would be a bad idea. One thing I can think of is that we would need to > measure the increase in memory usage and startup time for these processes. > I'm hoping it will be minimal. Yes, I'd be concerned about memory overhead.
Can you define what "minimal XPCOM" means? I'd really like us to split "XPCOM" into subsystems. e.g. "threading/event loop (with or without GUI)", "component manager", "profile handling". And then decide which startup notifications and component intializations belong to each thing. I really doubt we can make this work otherwise, because the memory and perf cost of initializing components is high. Why do MozPromises need XPCOM? For the event loop?
I guess I really only care about the thread manager and event loop. NS_InitMinimalXPCOM also initializes the component manager and the cycle collector, which would be nice to avoid for plugins and GMP. Maybe it would be best just to initialize the thread manager by itself. Mostly I want to be able to move away from all the complexity of MessagePumps and MessageLoops. That will be a lot more work than this bug, I guess.
Occasionally I find myself wishing I had XPCOM inside the GMP processes, but normally it's not a big issue. Supporting MozPromise for IPC inside the GMP process would be nice however. Most of XPCOM we don't need in the GMP process, so some sort of minimal set of XPCOM would be preferable. Note the GMP process has a pretty tight sandbox, so that may prevent parts of XPCOM working properly anyway.
You need to log in before you can comment on or make changes to this bug.