Try launching privileged content process asynchronously as soon as possible after main process start

ASSIGNED
Assigned to

Status

()

enhancement
P3
normal
ASSIGNED
4 months ago
2 months ago

People

(Reporter: mconley, Assigned: dthayer)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxperf:p1])

As of now, the privileged content process starts up as soon as the first browser attempts to visit about:home / about:newtab. The delay of loading that content process might be avoided if we:

  1. Launch the privileged content process as soon as possible after main process start
  2. Have that launch occur off of the main thread

In the event that the user is restoring a session, or is not configured to ever load about:newtab / about:home, we might want to find a way of reclaiming the memory of the unused process - perhaps by having the Privileged Content Process shut down if there are no associated tabs within some time after browser start-up.

Comment 1

4 months ago

With bug 1487287 backed out, I'm not sure how hard it'll be to do this. Mike, do we have a sense of what the impact would be here?

Flags: needinfo?(mconley)
Reporter

Comment 2

4 months ago

I think we need to depend on bug 1487287 to avoid adding extra work to the main thread.

I don't have a great expectation of impact just yet, but it does strike me that we could probably launch the content processes off of the main thread while the parent process is busy getting various other things started up (as it stands, we wait until the point at which we insert a remote <xul:browser> into the DOM)

Flags: needinfo?(mconley)

I think this only needs to depend on bug 1446161, which created a facility to launch content processes without blocking the main thread. Bug 1487287 is about which thread actually calls into the OS to do the launch: currently this is a non-main thread, but it's the same non-main thread that sends/receives the serialized IPC messages (called “the I/O thread” in the IPC code), which isn't ideal.

(Bug 1487287 is also about to land again, so it may not matter, but it's been backed out twice already and it's possible there's something else I've overlooked.)

Reporter

Comment 4

4 months ago

(In reply to Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧ from comment #3)

I think this only needs to depend on bug 1446161, which created a facility to launch content processes without blocking the main thread.

Ah, that's great! Thank you!

Depends on: 1446161
No longer depends on: 1487287

Comment 5

3 months ago

This seems relatively high prio to at least investigate.

Whiteboard: [fxperf] → [fxperf:p1]
Assignee

Comment 6

3 months ago

I'll try to fit this in between doc splitting builds and reviews, but if anyone has an abundance of time please feel free to take it.

Assignee: nobody → dothayer
Status: NEW → ASSIGNED
Reporter

Updated

3 months ago
Blocks: 1527936
Reporter

Comment 7

3 months ago

I suspect that we could use the preallocated process manager for this, if we can get it to allocate its first content process earlier, and if we can get the content processes it allocates to "mutate" to the right kind needed for the initial browser tab.

I filed bug 1521839 for this before I remembered that I'd filed this one, so duping.

Reporter

Updated

3 months ago
Duplicate of this bug: 1527929

Updated

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