memory usage way up on intex branch

[mykmelez]

On the startup benchmark, with the compiler disabled, the intex branch is much faster than master at starting WhatsApp, but memory usage is way up, because jsObjectsSize has ballooned:

Config	Value
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) Gecko/20100101 Firefox/42.0
Rounds	30
Delay(ms)	5000
Delete FS	no
Delete JIT CACHE	no
Warm startup	no

Test	Baseline Mean	Mean	+/-	%	P	Min	Max
startupTime	2,012ms	1,324ms	-688ms	-34.20	BETTER	1,302ms	1,353ms
vmStartupTime	210ms	197ms	-13ms	-6.03	BETTER	189ms	206ms
bgStartupTime	55ms	38ms	-18ms	-31.96	BETTER	36ms	41ms
fgStartupTime	1,315ms	780ms	-534ms	-40.64	BETTER	763ms	804ms
fgRefreshStartupTime	433ms	309ms	-124ms	-28.55	BETTER	294ms	320ms
fgRestartTime	n/a	NaNms	n/a	n/a	n/a	Infinityms	-Infinityms
totalSize	25,416kb	153,160kb	127,744kb	502.61	WORSE	152,824kb	153,431kb
domSize	160kb	161kb	1kb	0.37	SAME	161kb	161kb
styleSize	375kb	375kb	0kb	0.00	SAME	375kb	375kb
jsObjectsSize	17,521kb	147,665kb	130,144kb	742.78	WORSE	147,662kb	147,672kb
jsStringsSize	438kb	410kb	-28kb	-6.42	BETTER	410kb	411kb
jsOtherSize	6,698kb	4,326kb	-2,372kb	-35.41	BETTER	3,991kb	4,597kb
otherSize	223kb	223kb	0kb	-0.11	BETTER	223kb	223kb
USS	n/a	NaNkb	n/a	n/a	n/a	Infinitykb	-Infinitykb
peakRSS	311,997kb	678,842kb	366,844kb	117.58	WORSE	608,172kb	685,064kb

[mbebenita]

Is this before or after the removal of the ref array?

[mykmelez]

Is this before or after the removal of the ref array?

This is after its removal. I'm comparing my master-disable-compiler branch, which is the master branch with this small set of changes to disable the compiler, against my intex-jit-disable-compiler branch, which is @brendandahl's intex-jit branch with this change to disable the compiler.

[brendandahl]

Memory usage can easily be changed by tuning ASMJS_TOTAL_MEMORY. We currently allocate 134,217,728bytes. Seems to start fine and run with 16,777,216.

[mykmelez]

Setting _ASMJS_TOTALMEMORY to 16*1024*1024 reduces jsObjectsSize significantly, although memory usage is still higher in the startup benchmark:

Test	Baseline Mean	Mean	+/-	%	P	Min	Max
startupTime	2,012ms	1,318ms	-694ms	-34.51	BETTER	1,281ms	1,366ms
vmStartupTime	210ms	171ms	-38ms	-18.24	BETTER	156ms	186ms
bgStartupTime	55ms	38ms	-17ms	-31.65	BETTER	36ms	45ms
fgStartupTime	1,315ms	856ms	-459ms	-34.88	BETTER	793ms	900ms
fgRefreshStartupTime	433ms	253ms	-180ms	-41.61	BETTER	221ms	319ms
fgRestartTime	n/a	NaNms	n/a	n/a	n/a	Infinityms	-Infinityms
totalSize	25,416kb	38,525kb	13,109kb	51.58	WORSE	38,182kb	38,775kb
domSize	160kb	161kb	1kb	0.37	SAME	161kb	161kb
styleSize	375kb	375kb	0kb	0.00	SAME	375kb	375kb
jsObjectsSize	17,521kb	32,977kb	15,456kb	88.21	WORSE	32,974kb	32,981kb
jsStringsSize	438kb	410kb	-28kb	-6.42	BETTER	410kb	410kb
jsOtherSize	6,698kb	4,378kb	-2,319kb	-34.63	BETTER	4,038kb	4,628kb
otherSize	223kb	223kb	0kb	-0.12	BETTER	223kb	223kb
USS	n/a	NaNkb	n/a	n/a	n/a	Infinitykb	-Infinitykb
peakRSS	311,997kb	336,545kb	24,547kb	7.87	WORSE	325,184kb	361,532kb

But perhaps this isn't a fair comparison, since the intex branch preallocates all memory for the VM heap in advance. A better metric would compare memory usage over the application's lifetime. @marco-c mentioned that his tests suggest WhatsApp never uses more than about 30MB, so if we were to set _ASMJS_TOTALMEMORY to, say, 32*1024*1024 and watch memory usage while using the app, then we might have a better sense of max memory usage on the intex branch.

(We might also be able to keep _ASMJS_TOTALMEMORY at 16*1024*1024 with more aggressive garbage collection or other strategies. We haven't tuned the new interpreter for memory usage yet, and there may well be significant headroom.)

[mbebenita]

As far as I know, we currently have 2 asm.js heaps. One for the relooper, and one for Boehm GC. We should compile these two C/C++ codebases together so they can share the same heap.

[marco-c]

But perhaps this isn't a fair comparison, since the intex branch preallocates all memory for the VM heap in advance. A better metric would compare memory usage over the application's lifetime.

There's a different Emscripten option that allows growing the heap automatically, but AFAIK it's slower. It also doesn't allow actually releasing memory (see https://bugzilla.mozilla.org/show_bug.cgi?id=855669).

@marco-c mentioned that his tests suggest WhatsApp never uses more than about 30MB, so if we were to set ASMJS_TOTAL_MEMORY to, say, 32_1024_1024 and watch memory usage while using the app, then we might have a better sense of max memory usage on the intex branch.

Yes, I tested running WA for a while and its heap never grew to more than 20-30 MB (I don't recall precisely, but I can test again).

As far as I know, we currently have 2 asm.js heaps. One for the relooper, and one for Boehm GC. We should compile these two C/C++ codebases together so they can share the same heap.

Right: https://github.com/mozilla/pluotsorbet/issues/1615. The relooper's heap is quite small though, 512 kB.

(We might also be able to keep ASMJS_TOTAL_MEMORY at 16_1024_1024 with more aggressive garbage collection or other strategies. We haven't tuned the new interpreter for memory usage yet, and there may well be significant headroom.)

There's a Boehm option for small heap sizes that could be interesting: https://github.com/mozilla/pluotsorbet/issues/1627

[marco-c]

With #1787, #1785 and #1784, the heap grows to a maximum of 2162688 bytes (I've performed a quick test, it could be more if we use WA more). We should re-run the startup benchmark once they land.

[marco-c]

We need to test more and improve memory usage on the intex branch, but we're now definitely better than the first picture depicted in https://github.com/mozilla/pluotsorbet/issues/1780#issue-99267917.