NuwaTemplateProcess: Difference between revisions

adding description of what nuwa do for preloading.
(adding description of what nuwa do for preloading.)
 
Line 48: Line 48:
== Share Data Among Content Processes ==
== Share Data Among Content Processes ==
With Nuwa, static data could be shared among content processes with just one copy and copy-on-write.  If you think some deserve to be shared, you should load it at the Nuwa process before being frozen.  PreloadSlowThings() is a good place to load/or initialize the data.  Please check dom/ipc/preload.js of m-c.
With Nuwa, static data could be shared among content processes with just one copy and copy-on-write.  If you think some deserve to be shared, you should load it at the Nuwa process before being frozen.  PreloadSlowThings() is a good place to load/or initialize the data.  Please check dom/ipc/preload.js of m-c.
== Preloading ==
Preloading in B2G is a mechanism that loads assets and modules prior to opening an app to improve the app loading time. Preloading in Nuwa can leverage Nuwa's copy-on-write advantage to minimize memory space occupied by preloaded data shared accross process. However, there are 2 reasons that make preloading not be able to run in Nuwa.
* Preloading modules initiate asynchronous tasks, some of the tasks are even dispatched to chrome process through IPC. The asynchronous natural makes Nuwa hard to determine whether or not all of the tasks are done and to decide when to freeze. A callback invoked after Nuwa frozen can make Nuwa's main thread try to acquire a lock held by a frozen thread, which results in deadlock.
* Some modules setup ppmm/cpmm-based communication channels in there initialization processes. Since the channels are not based on IPDL, Nuwa won't duplicate the channels for the newly-forked process, thus the communication channels have to be built again after a process has been forked from Nuwa.
To address the first issue, a method of determining whether the task are all done or not has been proposed. The idea is that we monitor each thread in chrome process, and see if there's a moment that all of the threads are idle. Since we are not accessing network during boot, having all of the threads idle means all of the tasks previously generated are consumed, and Nuwa can freeze.
The second issue is addressed by splitting preload.js into 2 parts. The first part is where to put modules that are good to be loaded in Nuwa, while the second part contains modules that are not suitable to be loaded in Nuwa and scripts that rebuild communication channels. See
* Bug 970307
10

edits