I've got a demo here (Luke Wagner knows which/what) that uses a lot of memory while it's loading compiling -- during the initial phases, about:memory shows ~500-600 MB in use by "analysis_temporary", causing the page to use something like 1.1-1.2GB. After it gets going, that memory gets freed, and the page drops down to only using 600MB. This is the difference between being able to run this on mobile and not ;) Is there anything that can be done to reduce the memory usage, or make it more incremental? We're talking about 28MB of minified JS, so it's a fairly large chunk of JS to begin with.

Can't reduce memory usage of a demo we don't have.

Please get in touch with Vlad to get that demo.

Or Luke if he's nearer to you in the office.

Or me.

I instrumented an x86 browser to track how much memory is added to analysis-temporary during each analysis phase and during compilation, and ran it on the demo in question. I get these counts, in bytes: analyzeBytecode: 354113059 analyzeLifetimes: 5877872 analyzeSSA: 163016044 analyzeTypes: 162622560 compile: 46122148 This totals to 732MB, nearly half of it just in the Bytecode structures used when monitoring types and as the backbone for later analysis phases. I don't think there's much, if anything, to cut that would reduce this usage outright. Instead, I think that we should have a way to purge the analysis-temporary data without requiring discarding of jitcode. We could do this independently from GC, e.g. purge at whatever threshold for memory constrained devices. Purging still needs to retain information to ensure that jitcode is invalidated as type information changes, but the storage for that data should be comparable to the 'compile' number above. How much usable memory is available for the demo on mobile?

~500-700MB (1GB devices in general, 700MB is pushing it... 500MB is a safe target, though most everything else on the system would get killed off. It would still be 'a lot'.) Though I see the memory usage drop drastically once the demo actually starts -- do you see that as well? Does that mean we dumped the jitcode as well?

For this demo I don't think 500MB is doable, as it allocates a 400MB typed array and the baseline data for the scripts will occupy much of the remainder. 600MB as you saw is more realistic. What's nice about the approach outlined in comment 5 / bug 778724 is that there's relatively little finger-crossing needed; we can just set a ceiling for analysis + jitcode data, and purge or discard when we get above that. I didn't see a drop off at the same degree as you saw, but something like what you saw definitely makes sense if the demo is running a lot more code at startup than later on. Seeing a dropoff in analysis-temporary means a GC threw away both the analysis data and all jitcode. This isn't normally supposed to happen while playing animations, but could certainly still be triggered with the long delays between frames during startup here. After that GC, not as much different code is running so we do less analysis and less compilation. It could be possible to get the demo to work on mobile today by just GC'ing constantly to discard data and keep memory usage down, but bug 778724 should behave better when the page is running a lot of code.

Yeah, 600MB should definitely be fine. Will wait for bug 778724 :)

MemShrink bug. Fixed?

Given this bug's age, plus the fact that "analysis-temporary" and other type inference memory buckets no longer exist, I think we can close this.