792144 - [ARMv6] Tweak JS JIT options

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

Disabling the JIT may result in reduced memory usage (although will probably impact page load time/interaction unacceptably). We should be able to check about:memory under different browsing conditions to see how much memory is being used by the JIT on average, and whether or not it's worth disabling.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Adding Brian who has worked on this before, even though he seems to be away right now. I'll try to find somebody else from the JS team who can advise us on tuning the JIT to improve the memory situation without impacting JS execution time too much.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Renaming bug so that it better reflects the new goal: to adjust the JIT so that we trade performance for reduced memory usage on ARMv6 (or other low-memory) devices.

:djvj suggested talking to :dvander (who appears to already be CC'd on this bug). Any thoughts on what I can try for reducing memory usage by the JIT?

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Could you give more information on what the memory usage is currently like? There are a few things we could tweak but it helps to know the current state of things.  For example we could disable JM entirely for chrome (especially if the UI is not chrome-heavy), or look into other heuristics about how soon we compile code or how often we throw it out.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Attachment: about:memory dumps at various points

Sure. If there's specific memory information you'd like, let me know. Otherwise I've attached a log of about:memory data taken at various points from a single run of a recent inbound ARMv6 fennec build. The log lines are of the form:

<timestamp> E/GeckoConsole( pid): [AboutMemoryDump|identifier] <data>

All of the lines with the same "identifier" piece belong to the same about:memory dump. The identifiers are listed below; I imagine the TabsOpen* ones are the most useful for this bug.

Start - Right after the browser is opened
StartSettled - Start + 30 seconds of waiting
TabsOpen - After opening 17 sites from tp5 (all in separate tabs)
TabsOpenSettled - TabsOpen + 30 seconds of waiting
TabsOpenForceGC - TabsOpenSettled + forced GC
TabsClosed - After closing all the 17 tabs that were opened
TabsClosedSettled - TabsClosed + 30 seconds of waiting
TabsClosedForceGC - TabsClosedSettled + forced GC

(These are equivalent to the data points on areweslimyet.com)

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Ping. :dvander, if you're too busy to look into this now, is there somebody else who could?

Alternatively, is there documentation for the which prefs/constants can be fiddled with to tune this and what they do? I could try playing around with the settings myself if I know which ones to fiddle with. I see some javascript.options.mem.* options listed in mobile/android/app/mobile.js but I'm not sure if there's any others and I'm not clear on exactly what each of those control.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Kats - Bug 799656 made some changes for the low memory phones used by b2g. Maybe we could tweak our ARMv6 settings based on this.

Comment 7

[Andrew McCreight [:mccr8]]

That affects the GC behavior, not how the JIT uses memory, but it would still be worth looking at.

Comment 8

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to Kartikaya Gupta (:kats) from comment #4)
> Created attachment 664207 [details]
> about:memory dumps at various points

It looks like at any given point, JM code usage is around 250KB-590KB, and JM data usage is around 65KB. Ion is 0, since it doesn't run on ARMv6. analysis-temporary is quite high though.

Kats, could you try another memory dump? bug 793740 landed a few days after the old one, and it disabled Type Inference on ARMv6, which should drop analysis-temporary use to 0.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Attachment: about:memory dumps at various points (cset a10052ea8e72)

Thanks for the analysis!

I've attached another memory dump from cset http://hg.mozilla.org/integration/mozilla-inbound/rev/a10052ea8e72 (a few days old, but has the change you requested). The format of the dump file has changed, so now it's in the form:

filename
{
 ... memory dump info in JSON
}
filename2
{
 ... memory dump info in JSON
}

and so on. The "filename" contains the same tokens as before ("Start", "StartSettled", etc.) so hopefully it's not too much effort to read the file.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Ping. Please note that the in memory dump that I posted in comment #9 (and also in a more recent one I got off the latest m-c build) analysis-temporary is still nonzero. It sounds like that is not expected?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Attachment: about:memory dumps at various points (cset 2fc15ea29e20)

analysis-temporary is nowhere to be found now. I'm not sure if there's any other JIT settings that need to be tweaked.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

After discussion with :dvander on IRC it seems there's nothing else to do for this bug. There is a plan to get rid of the analysis-temporary memory entirely (bug 804676) which should help mobile as well.

Comment 13

[Nicholas Nethercote [inactive]]

> analysis-temporary is nowhere to be found now.

Bug 804891 is probably the reason.