Closed Bug 890870 Opened 7 years ago Closed 6 years ago
Use a deterministic point to freeze of the Nuwa process
Refer to bug 771765 comment #75. Currently we schedule a 1 sec timer in the Nuwa process to start freezing the thread. This is nondeterministic between different devices and even between a different runs on the same device. We need a more deterministic way to do this.
Summary: Deterministic signalling the freeze of the Nuwa process → Use a deterministic point to freeze of the Nuwa process
This blocks actually turning Nuwa on, so P1.
Kyle, how do you think about the patch in the patch from Cervantes? It freezes the Nuwa process after returning from PreloadSlowThings(). At that point, preload.js has loaded all preloaded scripts.
(In reply to Thinker Li [:sinker] from comment #3) > Kyle, how do you think about the patch in the patch from Cervantes? > It freezes the Nuwa process after returning from PreloadSlowThings(). At > that point, preload.js has loaded all preloaded scripts. That sounds good to me. Have we tested it? Does everything work?
As I tested, it works as expected. But the number of threads frozen can fluctuate in about 2 threads. I haven't looked into it deeper to see if this is really a concern. We still don't know will this allow us to share more or less memory, or how much faster this makes the Nuwa process become ready on faster devices.
Thinker suggested that we perform one GC before we freeze the Nuwa process so the cloned processes don't waste time collecting garbage again. I think adding ContentChild::GetSingleton()->RecvGargageCollect() should suffice.
That seems reasonable.
Some tests: On unagi it takes about 1.6 seconds to start freezing the Nuwa process. That is, the 1 second delay to freeze could be too small for unagi. We expect faster devices (especially those with a dual core CPU) to benefit from this patch and don't need to wait for such a long time as on unagi. About the added GC call, calling GC takes about 60 ms and saves about 200k PSS memory: Nuwa process memory usage without GC (tested 3 times) PID Vss Rss Pss Uss cmdline 5963 24124K 24124K 10913K 5288K /system/b2g/plugin-container 7050 24112K 24112K 10911K 5300K /system/b2g/plugin-container 7354 24132K 24132K 10911K 5292K /system/b2g/plugin-container Nuwa process memory usage with GC (tested 3 times) 6247 24140K 24140K 10768K 5032K /system/b2g/plugin-container 6633 24132K 24132K 10788K 5072K /system/b2g/plugin-container 6852 24092K 24092K 10735K 5004K /system/b2g/plugin-container
Try submission: https://tbpl.mozilla.org/?tree=Try&rev=e179116f3f20
Attachment #827308 - Flags: review?(khuey) → review+
(In reply to Cervantes Yu from comment #9) > About the added GC call, calling GC takes about 60 ms and saves about 200k > PSS memory: After we have a compacting GC it will make even more sense to do GC, because then we can share the compacted heap between the forked processes.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
I looked at the patch, and it doesn't seem as if Nuwa is enabled by default yet. Is that right? If so, do we have a bug open for doing that?
The bug that this bug blocks, bug 930282.
> The bug that this bug blocks, bug 930282. Ah, thanks. One of these days I should learn how to use teh Bugzilla.
You need to log in before you can comment on or make changes to this bug.