On Fri, Feb 21, 2014 at 9:56 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: >> >>> If your data is read-only after the point at which Nuwa forks the >>> process (which is once things are mostly loaded but before we load the >>> app) then generally yes. It's copy-on-write at page granularity of >>> course, so if you have sub-page allocations you can't guarantee that >>> it won't be copied. >> >> That sounds promising. Is there a way to test whether this is, in fact, >> happening for the self-hosting compartment? > > Not that I know of. The OS knows which memory pages are shared, but if > it's anonymously mapped data (as the entire malloc heap and GC heaps > are) you can only get data for entire segments, which are usually many > pages. And knowing which segment(s) the relevant data is in is also > difficult.
However, Thinker said this: "For now, Nuwa is frozen after RecvAppInfo(), from IPC, where PreloadSlowThing() is called. It is started by posting a runnable. So, all runnables posted before Nuwa's one is expected to be run before Nuwa is frozen. XPCOM is initialized before posting Nuwa's runnable." So that should give you a decent idea. It's also worth noting that if you have a mixture of mutable and immutable data, it might be worth trying to segregate them. E.g. if you have a Nuwa-shared page and you modify 1 byte, the entire 4 KiB page will be copied by the modifying content process. (https://bugzilla.mozilla.org/show_bug.cgi?id=948648 is open to look for instances of this.) Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
