> There are a few things we're working on in SpiderMonkey that should improve > this situation quite a bit:
Thanks, but I again need to emphasize that these are large, long-term plans. Terrence tells me that GGC is planned for "sometime this year". Lazy bytecode generation has been on the roadmap for a long time as well. I understand that these are large projects, and I don't mean to suggest that you guys aren't doing a good job with them, but I do not think that the right solution for b2g system compartments / workers is "JS should be able to meet your requirements one day," and "wait until things get better." In the meantime we continue to dig ourselves in a hole by implementing new DOM APIs in JS. We of course still want these engine improvements for reducing the memory usage of web content. Again, in the past, we've had the most success dealing with the JS engine as it is today. Then the engine optimizations, when they come, are gravy. That's all I'm suggesting we do here. On Mon, Apr 22, 2013 at 4:25 PM, Till Schneidereit <tschneider...@gmail.com> wrote: > There are a few things we're working on in SpiderMonkey that should improve > this situation quite a bit: > > Terrence already mentioned generational GC, which certainly is the largest > piece by far. Getting rid of all or almost all memory lost to fragmentation > makes the tradeoff a considerably different one, I'd say. > > Additionally, the work on making bytecode generation lazy[1] should vastly > reduce the memory used for scripts. Based on that, I'm investigating > several more options to reduce script memory: > - re-lazyfication of JSScripts, reducing memory usage by removing the > parsed represantation of scripts that are only run once or very rarely. > - lazy cloning of JSScripts with the same source from other compartments > containing the same script. Probably to go hand-in-hand with > re-lazyfication. > > Combined, I'd very vaguely say that these measures should reduce the memory > usage by an additional 20 or 30 percentage points. (Based on the current > usage as 100%, and no guarantees, of course). > > > > > On Mon, Apr 22, 2013 at 8:44 PM, Terrence Cole <tc...@mozilla.com> wrote: > >> On 04/22/2013 12:12 PM, Jeff Muizelaar wrote: >> > On 2013-04-22, at 2:15 PM, Bill McCloskey wrote: >> > >> >> I can't agree with you more, Justin. I think Boris is right that we >> should make these decisions on a case-by-case basis. But in the case of >> these workers, it seems clear that converting them to C++ is the way to go, >> assuming we have the resources to do so. >> > So a specific case that I ran into during the Performance Workshop is >> RILContentHelper.js. During the startup of the settings app >> > we jank for 53ms while initializing the RILContentHelper.js: >> > >> > >> http://people.mozilla.com/~bgirard/cleopatra/#report=bf7077c6552fe2bc015d7074a338b673911f3ce8&search=Mobile >> >> That link gives me this: "Error fetching profile :(. URL: >> ' >> http://profile-store.commondatastorage.googleapis.com/bf7077c6552fe2bc015d7074a338b673911f3ce8 >> '. >> Did you set the CORS headers?" >> >> > >> > There doesn't seem to be anything specific taking that much time in the >> profile, just general JS overhead. In this case RILContentHelper.js is >> wrapped by by C++ code in dom/network/src/MobileConnection.cpp and so we >> end up spending a fair amount of time transitioning from JS to C++ to JS to >> C++. >> >> That seems like the sort of thing that SpiderMonkey may be able to >> address in the short term, depending on what exactly it turns out to be. >> Is there a bug on file somewhere to coordinate the investigation? >> >> -Terrence >> >> > -Jeff >> > _______________________________________________ >> > dev-platform mailing list >> > dev-platform@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-platform >> >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
