If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Nuwa process can accumulate IPC messages




4 years ago
4 years ago


(Reporter: khuey, Assigned: khuey)




Firefox Tracking Flags



(Whiteboard: [c=memory p= s= u=1.3])


(2 attachments)

I believe it is possible for the Nuwa process to accumulate IPC messages that are broadcast to all processes.  This means that every time the Nuwa process forks and "wakes up" all of those messages will be processed.  This could slow down app startup (especially if memory-pressure notifications which trigger GC/CC are queued up).  We should probably not broadcast messages to the Nuwa process.


4 years ago
blocking-b2g: 1.3? → 1.3+
Keywords: perf

Comment 1

4 years ago
Patrick, is this something you can take?  Just trying to make sure we have coverage on 1.3+ bugs.  Thanks!
Flags: needinfo?(pwang)


4 years ago
Priority: -- → P1
Whiteboard: [c=memory p= s= u=1.3]
Nuwa can process IPC message even when it is ready for forking new process. We are trying to figure out if this really happen.
Flags: needinfo?(pwang)


4 years ago
Assignee: nobody → pwang
Created attachment 8362830 [details] [diff] [review]

I added some log to look the length of mPending in MessageChannel. After Nuwa process is frozen, the MessageQueue can still go back to zero.

I think that all messages dispatched to main thread can be processed. Only when the message makes main thread try to acquire lock which a frozen thread holds, it would cause Nuwa frozen. (Like https://bugzilla.mozilla.org/show_bug.cgi?id=941466#c0)
Created attachment 8362831 [details]
message queue log
Patrick, is there any follow up here?
Based on the log, I don't think IPC messages are queued when Nuwa is frozen. Kyle, do you think we need to do more investigation?
Flags: needinfo?(khuey)
Yes, you are correct.  It is however possible for those IPC messages to result in queueing up events on the main thread such as memory pressure notifications which will have to run every time we fork the Nuwa process.

I will take this.
Assignee: pwang → khuey
Flags: needinfo?(khuey)
For memory pressure, the Nuwa process just ignores it by returning true in ContentChild::RecvFlushMemory(). So the remaining problem is: is it possible that the main thread's queue has pending IPC message to run ContentChild::RecvFlushMemory() where it is supposedly to be ignored but the delayed execution of IsNuwaProcess() becomes false in the forked child?

This is how the NuwaFork() request runs in the Nuwa process:
1. The IPC thread receives the request and dispatch ContentChild::RecvNuwaFork() to the main thread.
2. The main thread dispatches RunNuwaFork() to the IPC thread.
3. RunNuwaFork() dispatch a runnable to the main thread to fork(). This is synchronous. The IPC thread is blocked until the main thread finishes fork().

So the main thread's run queue should be empty when it forks, even we receive GC requests between 2 and 3. It is possible that other threads might have runnables queued up when it is frozen. But they are unlikely, if ever possible, the GC requests.
Ah, yes, you are correct.  Guess I should read code before filing bugs ;)
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.