Relocatable JIT Code

[mbebenita]

This backs out some of the previous work on code caching, applies some optimizations that I had in my previews patch queue and then re-lands code caching but using relocatable JIT code instead of trying to come up with unique class ids.

[mbebenita]

This should be merged after #1831

[mykmelez]

I'll review this once #1831 lands.

[mykmelez]

It looks like this needs conflict resolution (which should also help to hide the changes in the branch from which it branched, so it's easier to review).

[mykmelez]

@mbebenita Would you merge intex into this so its conflicts are resolved?

[mbebenita]

Hmm, i thought I had merged. Let me look at it again.

[mbebenita]

Okay, should be merged now.

[mykmelez]

Startup time improves on this branch, although startup memory usage gets worse:

Test	Baseline Mean	Mean	+/-	%	P	Min	Max
startupTime	985ms	897ms	-88ms	-8.92	BETTER	872ms	962ms
vmStartupTime	188ms	177ms	-11ms	-5.63	BETTER	160ms	202ms
bgStartupTime	43ms	43ms	0ms	-1.01	SAME	41ms	45ms
fgStartupTime	639ms	572ms	-67ms	-10.44	BETTER	542ms	635ms
fgRefreshStartupTime	115ms	105ms	-10ms	-8.81	BETTER	90ms	119ms
fgRestartTime	n/a	NaNms	n/a	n/a	n/a	Infinityms	-Infinityms
totalSize	34,437kb	35,916kb	1,480kb	4.30	WORSE	34,616kb	36,757kb
domSize	171kb	171kb	0kb	-0.00	SAME	170kb	171kb
styleSize	396kb	396kb	0kb	-0.04	SAME	395kb	398kb
jsObjectsSize	26,790kb	28,902kb	2,112kb	7.88	WORSE	28,883kb	28,910kb
jsStringsSize	497kb	501kb	4kb	0.77	WORSE	493kb	503kb
jsOtherSize	6,346kb	5,710kb	-636kb	-10.02	BETTER	4,433kb	6,545kb
otherSize	237kb	237kb	0kb	-0.01	SAME	224kb	239kb
USS	n/a	NaNkb	n/a	n/a	n/a	Infinitykb	-Infinitykb
peakRSS	393,481kb	410,101kb	16,619kb	4.22	WORSE	405,948kb	410,292kb

[mbebenita]

The size of the FT map used to be maxClassId << 8. During startup the maximum class id is about 600, so the array can become ~ 600 << 8 = 150K entries x 8 bytes per entry, ~ 1MB or so. This consumes both memory and probably hurts startup time because the array needs to be nulled out. I've now changed the maxVTableSize to 64 instead of 256. The size of the array is now 600 << 6 = 38K or so. I counted 5 virtual methods that are linked during startup which have virtual method indices larger than 64 and thus fail to be optimized, but we can probably live with the tradeoff. After playing with the app a few seconds, I see roughly 73 methods with IDs larger than 64:

65,70,71,69,109,104,101,109,109,124,108,131,108,109,131,104,101,108,131,112,114,113,115,91,92,92,99,99,87,99,99,110,133,133,124,110,95,91,95,112,114,113,115,92,91,95,112,114,113,115,91,64,73,85,83,95,81,104,64,99,78,95,118,71,76,64,64,74,102,69,66,80,77

[mykmelez]

The size of the array is now 600 << 6 = 38K or so. I counted 5 virtual methods that are linked during startup which have virtual method indices larger than 64 and thus fail to be optimized, but we can probably live with the tradeoff.

Thanks, that looks better, both at startup:

Test	Baseline Mean	Mean	+/-	%	P	Min	Max
startupTime	985ms	902ms	-84ms	-8.50	BETTER	862ms	919ms
vmStartupTime	188ms	185ms	-3ms	-1.48	SAME	156ms	206ms
bgStartupTime	43ms	42ms	-1ms	-1.59	BETTER	39ms	45ms
fgStartupTime	639ms	568ms	-71ms	-11.13	BETTER	544ms	591ms
fgRefreshStartupTime	115ms	106ms	-9ms	-7.93	BETTER	90ms	116ms
fgRestartTime	n/a	NaNms	n/a	n/a	n/a	Infinityms	-Infinityms
totalSize	34,437kb	34,378kb	-59kb	-0.17	SAME	33,124kb	35,210kb
domSize	171kb	171kb	0kb	-0.00	SAME	170kb	171kb
styleSize	396kb	396kb	0kb	-0.01	SAME	395kb	399kb
jsObjectsSize	26,790kb	27,366kb	576kb	2.15	WORSE	27,359kb	27,369kb
jsStringsSize	497kb	497kb	0kb	-0.01	SAME	492kb	498kb
jsOtherSize	6,346kb	5,712kb	-634kb	-9.99	BETTER	4,466kb	6,544kb
otherSize	237kb	236kb	-1kb	-0.32	SAME	224kb	239kb
USS	n/a	NaNkb	n/a	n/a	n/a	Infinitykb	-Infinitykb
peakRSS	393,481kb	392,625kb	-857kb	-0.22	SAME	374,640kb	401,688kb

And at runtime, in my measures of runtime memory usage after a midlet settles down on its initial screen.