Closed Bug 890870 Opened 7 years ago Closed 6 years ago

Use a deterministic point to freeze of the Nuwa process

Categories

(Firefox OS Graveyard :: General, defect)

x86_64
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cyu, Assigned: cyu)

References

Details

(Whiteboard: [MemShrink:P1])

Attachments

(1 file, 1 obsolete file)

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.
Whiteboard: [MemShrink: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.
Blocks: 930282
Attachment #812587 - Attachment is obsolete: true
Attachment #827308 - Flags: review?(khuey)
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
(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.
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/37ea5d4f246c
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.