928874 - "Where's my water?" OOMs on buri with high asm.js memory usage.

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Paul Yang [:pyang] (away)]

Attachment: memory-report.json.gz

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20131017030201

Steps to reproduce:

Install where's my water as packaged app
Launch the app


Actual results:

Blackscreen about 1 minute.  Get OOM message in dmesg
tools/get_about_message


Expected results:

App launched successfully

Comment 1

[Jason Smith [:jsmith]]

Note - this in itself isn't a blocker for release, as the app was expected to hit problems running on Buri (more generally, a 256 MB device). But we should investigate figuring out what needs to be fixed on the gecko side to make it possible to run this app on a 256 MB device.

Comment 2

[Sotaro Ikeda [:sotaro]]

How can we get 'where's my water'?

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

The attachment appears to be a desktop about:memory, from a browser with a number of other things open; it would help to get the memory info on a FxOS device (e.g., the keon, which has 512MB).

For those who didn't see the Summit demos: Where's My Water is a commercial phone game, ported to the web with Emscripten/asm.js; the port is still in an early stage, I think.  (Its existence is public as far as I can tell, but some details may be Do Not Tweet.)  In the desktop memory report it looks like it's using 64MB for the asm.js heap array (for C/C++/ObjC malloc), and another 19MB or so for regular JS objects (and maybe more that I'm missing), and 7 MB of compiled code.  So it's pretty sizable even before considering memory that's not explicitly allocated by the app.

Comment 4

[Sotaro Ikeda [:sotaro]]

(In reply to Jason Smith [:jsmith] from comment #1)
> Note - this in itself isn't a blocker for release, as the app was expected
> to hit problems running on Buri (more generally, a 256 MB device). But we
> should investigate figuring out what needs to be fixed on the gecko side to
> make it possible to run this app on a 256 MB device.

Actually all b2g system can use about 180MB on buri device.

Comment 5

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

Paul, the about:memory report you attached appears to be from your desktop, not the phone.  Can you grab the report from the device?  Feel free to come find me in the office if you need help.

Comment 6

[Paul Yang [:pyang] (away)]

Attachment: memory-report.tar.gz

Sorry for that, providing a correct memory report in attachment

Comment 7

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

Thanks Paul.

215.40 MB (100.0%) -- explicit
├──149.22 MB (69.27%) -- window-objects/top(app://3b495279-0614-4fe6-bdb9-528bc44f1299/index.html, id=1)
│  ├──147.62 MB (68.53%) -- active
│  │  ├──147.61 MB (68.53%) -- window(app://3b495279-0614-4fe6-bdb9-528bc44f1299/index.html)
│  │  │  ├──147.28 MB (68.38%) -- js-compartment(app://3b495279-0614-4fe6-bdb9-528bc44f1299/index.html)
│  │  │  │  ├──146.43 MB (67.98%) -- objects
│  │  │  │  │  ├──130.58 MB (60.62%) -- malloc-heap
│  │  │  │  │  │  ├──128.05 MB (59.45%) -- elements
│  │  │  │  │  │  │  ├──128.01 MB (59.43%) ── asm.js [2]

Virtually all of the memory usage here is in asm.js, so lets start there.

Comment 8

[Luke Wagner [:luke]]

That 128MB is the ArrayBuffer that gets used as the asm.js heap; it's just marked/reported as 'asm.js' because it was linked to an asm.js module.  Not only is there a big heap, but there is an even bigger typed array of assets that is created a little later in the loading processes.  I think everyone more directly involved (cc'ing mbest to verify) has no expectation of this game to run on the 256MB phones, so I'm pretty sure this is WONTFIX.  It would be useful, OTOH, to test on the 512MB devices.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Luke Wagner [:luke] from comment #8)
> That 128MB is the ArrayBuffer that gets used as the asm.js heap; it's just
> marked/reported as 'asm.js' because it was linked to an asm.js module.  Not
> only is there a big heap, but there is an even bigger typed array of assets
> that is created a little later in the loading processes.  I think everyone
> more directly involved (cc'ing mbest to verify) has no expectation of this
> game to run on the 256MB phones, so I'm pretty sure this is WONTFIX.  It
> would be useful, OTOH, to test on the 512MB devices.

We actually did try running this on a 512 MB device, but hit a gfx regression issue too early in usage to be able to test it effectively.

I am bit surprised that we would try to push for a partner app that won't work on many of our low end target Firefox OS devices. That seems to be against our target objectives for the Firefox OS project, which aim for targeting low memory devices. If need be, I can have a side discussion with Martin Best & Chris Lee about this more, as I'm concerned around targeting an ecosystem that doesn't meet our target low end devices.

Comment 10

[Luke Wagner [:luke]]

(In reply to Jason Smith [:jsmith] from comment #9)
If the game needs that much memory, then there's not much we can do.  Now, there are some improvements on the DOM side that should eventually allow us to not have to store the game's file system in memory (moving more WebAPIs to workers so that we can run the game in a worker so that we can use synchronous IDB to implement synch IO in the game) and THAT should allow us to perhaps squeeze games like WMW into a 256 MB device, but we're not there yet.