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
