runtime memory usage regression on intex branch

[mykmelez]

There's a runtime memory usage regression on the intex branch. When testing with RunWhatsApp, at three points during usage of the app on the master branch, I see USS of 70.1, 57.7, and 59.8 (MB); while on intex at those points it's 117.1, 64.6, and 69.3.

I'm testing on a recent eng build of FxOS 2.2 and measuring memory usage via b2g/tools/get_about_memory.py --minimize --no-gc-cc-log.

[mykmelez]

Chrome profiles of the JS heap also show RunWhatsApp using more memory on the intex branch. Even with the compiler disabled, and an 8MB ASM heap, I see a difference: 27.7MB on master, 36.4MB on intex for the initial screen. Strangely, intex reports interpreting many more bytecodes than master: ~4M for master, ~14M for intex.

[marco-c]

According to my measurements, after #1838 we could reduce the asmjs heap to 4 MB instead of 8. This would help, even if it wouldn't completely fix the memory regression.

[marco-c]

Strangely, intex reports interpreting many more bytecodes than master: ~4M for master, ~14M for intex.

I think WA doesn't always do exactly the same things on every startup, we should try measuring several times and getting an average memory usage.

[mykmelez]

Strangely, intex reports interpreting many more bytecodes than master: ~4M for master, ~14M for intex.

I think WA doesn't always do exactly the same things on every startup, we should try measuring several times and getting an average memory usage.

The bytecode interpretation count is different from memory usage (although it could affect it), but in any case it's consistent, as multiple starts on master all interpret ~4M bytecodes, while multiple starts on intex all interpret ~14M. Perhaps this is because intex is self-hosting strings?

[marco-c]

The bytecode interpretation count is different from memory usage (although it could affect it), but in any case it's consistent, as multiple starts on master all interpret ~4M bytecodes, while multiple starts on intex all interpret ~14M.

Yes, what I meant was that memory usage could be affected by what WA does at startup (since WA doesn't always do exactly the same things, although two executions should be reasonably similar), so we should run the measurements multiple times and calculate an average memory usage.
Anyway, a 10 MB difference is probably too big to be explained by this.

Perhaps this is because intex is self-hosting strings?

Good idea, I can't think of anything else that would affect the number of bytecodes executed.