Initialize minimal XPCOM in plugin and GMP processes

NEW
Unassigned

Status

()

Core
XPCOM
P3
normal
a year ago
6 months ago

People

(Reporter: billm, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

The fact that plugin and GMP processes cannot use XPCOM is a real headache. See [1] 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.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313200#c40
Flags: needinfo?(cpearce)
Flags: needinfo?(benjamin)
(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.

Comment 2

a year ago
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?
Flags: needinfo?(benjamin)
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.
Flags: needinfo?(cpearce)

Updated

6 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.