970360 - [gaia-ui-endurance] Increase in b2g memory consumption during add_contacts test

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Contacts, defect, P1)

Description

[Robert Wood [:rwood]]

The latest gaia-ui endurance tests on master hamachi are showing a significant increase in the main b2g process memory use (RSS) during the add contacts test. This test simply adds a new contact to the address book and repeats 150x.

The endurance tests are somewhat noisy so fluctuations are common, however this is larger than normal so thought I'd point it out in case there is something to be investigated here.

Latest results can be found on Datazilla:

https://datazilla.mozilla.org/b2g/?branch=master&device=hamachi&range=90&test=endurance_add_contact&app_list=browser,calendar,camera,clock,contacts,fm_radio,gallery,messages,music,phone,settings,usage,video&app=camera&gaia_rev=0d080de82ac2357a&gecko_rev=2e89bf81def53f9b&plot=avg

Have there been any significant changes to the gaia contacts app recently, that may increase memory consumption?

Info on how to run the gaia-ui endurance tests can be found at the link below. Note that they are run on master and v1.2 (not v1-train):

https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/endurance_tests/how_to_run_gaiaui_endurance_tests

Comment 1

[Jonathan Griffin (:jgriffin)]

Adding some folks who might be able to provide some input on this observation.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Did this change correspond to enabling APZC in the tests by any chance?

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I don't understand this graph.  The y-axis has units of ms.  What does this have to do with memory?

Comment 4

[Jonathan Griffin (:jgriffin)]

(In reply to Ben Kelly [:bkelly] from comment #2)
> Did this change correspond to enabling APZC in the tests by any chance?

APZC isn't on by default yet, is it?  APZC breaks touch events in Marionette, and we haven't landed a patch for that yet.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Kyle, the y-axis label is a known bug in datazilla.  I think jeads is working on it.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

I believe position:sticky landed recently in contacts.  Does the regression range match when bug 942460 landed?

Comment 7

[Robert Wood [:rwood]]

:bkelly Yes the timing is right for that - the first memory spike was seen on the first endurance test run where that change was included (started Feb. 8th 4pm EST)

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Why would a layout feature increase memory usage in the parent process?  Can we get before/after about:memory dumps here?

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

The position:sticky change required removing some overflow:hidden styles.  Maybe we are getting large layers and more gfx mem usage.  Doesn't the parent process handle all that gfx allocation code?

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

It's possible, yes.

Comment 11

[Robert Wood [:rwood]]

Attachment: http://people.mozilla.org/~rwood/add_contact/memory-dumps.zip

Link to about-memory dumps before and after running the add_contact endurance test (100 iterations), hamachi master build 20140212040203 git 2014-02-11 16:30:09 4c6b5142

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

It seems this might be related to bug 971694 as the regression dates are about the same.

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

There is a 20 MB regression in memory usage in the communications app.

20.06 MB (100.0%) -- explicit

I also see six new compartments in the app.

├───6 (54.55%) -- user
│   ├──1 (09.09%) ── app://communications.gaiamobile.org/contacts/index.html [+]
│   ├──1 (09.09%) ── app://communications.gaiamobile.org/contacts/index.html, [anonymous sandbox] (from: chrome://marionette/content/marionette-listener.js:361) [+]
│   ├──1 (09.09%) ── app://communications.gaiamobile.org/contacts/index.html, about:blank [+]
│   ├──1 (09.09%) ── app://communications.gaiamobile.org/facebook/curtain.html, about:blank [+]
│   ├──1 (09.09%) ── app://communications.gaiamobile.org/facebook/fb_oauth.html [+]
│   └──1 (09.09%) ── moz-nullprincipal:{b14340e3-8141-4da6-9370-2b882d12dfce} [+]

So I think there were gaia side changes here that caused this.  Did we turn on some Facebook thing?

Comment 14

[Ben Kelly [:bkelly, not reviewing]]

I'll take this.  Based on comment 13 I don't think its related to bug 971694.

Comment 15

[Ben Kelly [:bkelly, not reviewing]]

Bug 952691 is the only Facebook related change in the regression range.

Jose, should we be closing the FB iframes after trying to sync?

Comment 16

[Ben Kelly [:bkelly, not reviewing]]

Hmm, actually, the diff in comment 13 may be a bit misleading.  I looked at about-memory-0 in the provided zip and there is no Communications app at all.  So it seems like the memory reports are not comparing apples-to-apples.

I'm dropping the ni flag as its unclear to me this is facebook related after all.

I'll try to get the endurance test running locally to better investigate.  That probably won't happen until tomorrow, though.

Comment 17

[Nicholas Nethercote [inactive]]

Hmm, yes -- the "[+]" markers indicate entries that are present in the second dump but not in the first.

Comment 18

[Jose Manuel Cantera]

(In reply to Ben Kelly [:bkelly] from comment #15)
> Bug 952691 is the only Facebook related change in the regression range.
> 
> Jose, should we be closing the FB iframes after trying to sync?

Hi Ben,

FWIW, Cristian in bug 959414 made that change.

thanks

Comment 19

[Ben Kelly [:bkelly, not reviewing]]

For easy reference, here is the starting regression range:

  https://github.com/mozilla-b2g/gaia/compare/ac94739a01d64e86...d15809c5db9f57869d
  http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1f170f9fead0&tochange=cafe909f7e07

Lets see if I can reproduce with something less than 100 iterations of the test...

Comment 20

[Ben Kelly [:bkelly, not reviewing]]

I have a few more tests to run, but at this point I'm fairly certain that this is due to bug 968957 disabling OOP keyboards.  You can see we reduced parent process RSS by a similar amount on 12/23 when the keyboard first went to OOP.

It appears the parent process has also gained another 5MB somewhere in the last month, but that seems quite variable and its not clear when it occurred.

I need to run another test with just bug 968957 backed out, but if it shows a reduction I am going to close this as WFM.  I'll open a new bug for the other 5MB memory regression.

Comment 21

[Ben Kelly [:bkelly, not reviewing]]

I've verified that this is just the keyboard moving from OOP back into the parent process.  Since the fix for OOP keyboard with NUWA is being worked in bug 968991 I'm going to mark this WONTFIX.

I'm still investigating the other 5MB we've lost in the last month, but will open a new bug if I find anything significant.