842838 - With Ion enabled on b2g, demo keeps using up memory and eventually dies

Status: RESOLVED DUPLICATE of bug 843733

(Core :: JavaScript Engine, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

With Ion enabled on b2g (using mozilla-central from a few days ago), the demo installable from http://orcchop.playcanvas.com/install.html keeps chewing up memory as it runs and eventually gets killed off.  With ion disabled, it runs fine indefinitely and hovers at ~80MB RSS.  With ion enabled, it gets to 250MB and then can't go any more (tested on a 512MB Unagi and Peak).

This might also reproduce on Android, but I don't have a non-installable link.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Oh, non-install URL is just http://orcchop.playcanvas.com/

Comment 2

[Nicholas Nethercote [inactive]]

Memory reports from tools/get_about_memory.py, please!

Comment 3

[Geoff Brown [:gbrown]]

On Android, there is a similar memory leak evident when running Shumway demos: The pac3.swf demo, for example, uses so much memory that the browser is killed in about 5 minutes. With ion disabled, pac3.swf runs for at least 45 minutes without problem. I have about:memory dumps for this -- should I post them here, or open a separate bug?

Comment 4

[Andrew McCreight [:mccr8]]

Separate bug, please.

Comment 5

[Nicolas B. Pierron [:nbp]]

Attachment: B2G: JM memory usage over time.

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #0)
> With ion disabled, it runs fine indefinitely and hovers at ~80MB RSS.

I did a similar test, and the application crash because it hit the artificial cap of 100MB.  I attached the memory profile of the application captured with:

while true; do adb shell b2g-ps; done | \
  awk '/Orc Chop/ { print $7 }' > orcchop.mem

> With ion enabled, it gets to 250MB and then can't go any more (tested on a 512MB
> Unagi and Peak).

Can you detailed how you profiled that it was going to 250MB?  AFAIK, the Unagi kernel is patched to restrict it to 256MB, and there is a cap set to 100MB for applications.

Did you disable JM, or you have enabled JM+Ion?  Disabling JM would certainly cause more memory usage as Ion needs to encode snapshots, but I would not expect something with such a huge magnitude.

Testing this application in the browser (x64) show the following memory profiles, taken a few seconds after the load of the game. (The game never finish loading neither in the browser nor on the phone).  These profiles, even if taken slightly after the code execution, are showing that, when JM & Ion are enabled, Ion does not appear in the memory profile.  When JM is disabled, Ion appear as using 20 KB, which corresponds to at least 32 functions (as reported by the JIT Inspector).  When JM is disabled Ion is compiling after 40 iterations, I guess no functions are compiled with IonMonkey when JM & Ion are used together.

(With JM+TI)
│    │   ├──14.73 MB (01.04%) -- js/compartment
│    │   │  ├───7.20 MB (00.51%) -- type-inference
│    │   │  │   ├──5.44 MB (00.38%) ── analysis-pool [2]
│    │   │  │   ├──1.00 MB (00.07%) ── type-pool [2]
│    │   │  │   ├──0.69 MB (00.05%) ── type-scripts [2]
│    │   │  │   ├──0.06 MB (00.00%) ── allocation-site-tables [2]
│    │   │  │   └──0.01 MB (00.00%) ── pending-arrays
│    │   │  ├───4.51 MB (00.32%) -- gc-heap
│    │   │  │   ├──1.95 MB (00.14%) ++ objects
│    │   │  │   ├──1.01 MB (00.07%) ++ shapes
│    │   │  │   ├──0.62 MB (00.04%) ── unused-gc-things [2]
│    │   │  │   ├──0.57 MB (00.04%) ── scripts [2]
│    │   │  │   ├──0.14 MB (00.01%) ── type-objects [2]
│    │   │  │   ├──0.14 MB (00.01%) ++ strings
│    │   │  │   ├──0.07 MB (00.00%) ── arena-admin [2]
│    │   │  │   └──0.01 MB (00.00%) ── sundries [2]
│    │   │  ├───1.24 MB (00.09%) ── script-data [2]
│    │   │  ├───0.79 MB (00.06%) ++ objects-extra
│    │   │  ├───0.69 MB (00.05%) ++ shapes-extra
│    │   │  ├───0.18 MB (00.01%) ── jaeger-data
│    │   │  ├───0.10 MB (00.01%) ── string-chars/non-huge
│    │   │  └───0.04 MB (00.00%) ── other-sundries [2]

(With JM+Ion+TI)
│    │   ├──14.26 MB (01.02%) -- js/compartment
│    │   │  ├───6.75 MB (00.48%) -- type-inference
│    │   │  │   ├──5.41 MB (00.39%) ── analysis-pool [2]
│    │   │  │   ├──0.91 MB (00.07%) ── type-pool [2]
│    │   │  │   ├──0.36 MB (00.03%) ── type-scripts
│    │   │  │   ├──0.06 MB (00.00%) ── allocation-site-tables [2]
│    │   │  │   └──0.01 MB (00.00%) ── pending-arrays
│    │   │  ├───4.49 MB (00.32%) -- gc-heap
│    │   │  │   ├──1.98 MB (00.14%) ++ objects
│    │   │  │   ├──1.01 MB (00.07%) ++ shapes
│    │   │  │   ├──0.57 MB (00.04%) ── scripts [2]
│    │   │  │   ├──0.57 MB (00.04%) ── unused-gc-things [2]
│    │   │  │   ├──0.14 MB (00.01%) ++ strings
│    │   │  │   ├──0.14 MB (00.01%) ── type-objects [2]
│    │   │  │   ├──0.07 MB (00.00%) ── arena-admin [2]
│    │   │  │   └──0.01 MB (00.00%) ── sundries [2]
│    │   │  ├───1.24 MB (00.09%) ── script-data [2]
│    │   │  ├───0.79 MB (00.06%) ++ objects-extra
│    │   │  ├───0.68 MB (00.05%) ++ shapes-extra
│    │   │  ├───0.17 MB (00.01%) ── jaeger-data
│    │   │  ├───0.10 MB (00.01%) ── string-chars/non-huge
│    │   │  └───0.04 MB (00.00%) ── other-sundries [2]

(With Ion+TI)
│    │   ├──14.42 MB (01.09%) -- js/compartment
│    │   │  ├───6.84 MB (00.52%) -- type-inference
│    │   │  │   ├──5.34 MB (00.40%) ── analysis-pool [2]
│    │   │  │   ├──1.06 MB (00.08%) ── type-pool [2]
│    │   │  │   ├──0.36 MB (00.03%) ── type-scripts
│    │   │  │   ├──0.06 MB (00.00%) ── allocation-site-tables [2]
│    │   │  │   └──0.01 MB (00.00%) ── pending-arrays
│    │   │  ├───4.59 MB (00.35%) -- gc-heap
│    │   │  │   ├──2.02 MB (00.15%) ++ objects
│    │   │  │   ├──1.01 MB (00.08%) ++ shapes
│    │   │  │   ├──0.61 MB (00.05%) ── unused-gc-things [2]
│    │   │  │   ├──0.57 MB (00.04%) ── scripts [2]
│    │   │  │   ├──0.14 MB (00.01%) ++ strings
│    │   │  │   ├──0.14 MB (00.01%) ── type-objects [2]
│    │   │  │   ├──0.07 MB (00.01%) ── arena-admin [2]
│    │   │  │   ├──0.02 MB (00.00%) ── ion-codes
│    │   │  │   └──0.01 MB (00.00%) ── sundries [2]
│    │   │  ├───1.24 MB (00.09%) ── script-data [2]
│    │   │  ├───0.79 MB (00.06%) ++ objects-extra
│    │   │  ├───0.69 MB (00.05%) ++ shapes-extra
│    │   │  ├───0.14 MB (00.01%) ── ion-data
│    │   │  ├───0.10 MB (00.01%) ── string-chars/non-huge
│    │   │  └───0.04 MB (00.00%) ── other-sundries [2]

I assume that the browser test I have made are not reproducing exactly what was seen on the mobile device (even if I cannot determine why at the moment), otherwise this would mean that we are likely wasting at MB of memory.

At least, these figures give us an order of magnitude of the memory cost of Ion compilations *on x64*, which won't be my first bet in terms of memory usage.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #5)
> Can you detailed how you profiled that it was going to 250MB?  AFAIK, the
> Unagi kernel is patched to restrict it to 256MB, and there is a cap set to
> 100MB for applications.

Used a kernel that uses the full 512MB available.  I can provide a boot.img if needed..

> Did you disable JM, or you have enabled JM+Ion?  Disabling JM would
> certainly cause more memory usage as Ion needs to encode snapshots, but I
> would not expect something with such a huge magnitude.

Nope, no disabling; was JM+Ion.  I'll try to grab an about:memory snapshot once I'm back next week.

Comment 7

[Nicolas B. Pierron [:nbp]]

I did some testing on the unagi. The result I have so far are showing that octane cannot run at all with the memory cap which is in-place.

It was strange to notice that removing non-executed loaded code from the octane benchmark allow it to go further in its execution, which means that the JSScript size should be measured at some point.  Both with or without Ion running.  If this appear to be a real issue we should probably look into the lazy loading of bytecode as well as discarding bytecode which has not been used for a while.

The in-browser test of the octane benchmark are terrible compared to the JS shell benchmark ran on the device.  The JS shell benchmark scores have almost doubled with Ion compared to JM.  Enabling Ion in B2G is working fine on the octane benchmark, except that except Richards & NavierStroke benchmarks, none of these improvement seems to seems to be visible in the browser application.

# in-browser result on octane subset (with Ion):
Richards: 880
DeltaBlue: 101
Crypto: 467
RayTrace: 89.6    # Interrupt check
EarleyBoyer: 161
RegExp: 43.1
Splay: 62.4
NavierStokes: 1192
PdfJS: 167

Using the gcparam shell function give the ability to push the limit of the execution to run octane until the end of PdfJS, otherwise it tend to fail on it:

# JS shell result on octane subset (with Ion, gcparam "maxBytes" set to 60 MB (1)):
Richards: 832
DeltaBlue: 921
Crypto: 888
RayTrace: 707     # ~900 (maxBytes = 100MB)
EarleyBoyer: 856  # ~1075 (maxBytes = 100MB)
RegExp: 123
Splay: 94.9       # ~400 (maxBytes = 100MB), ~850 (no gcparam)
NavierStokes: 1223
PdfJS: 595        # Killed (no gcparam)

The xpcshell show the same figures as the JS shell.  Restricting the amount of space available to 60 MB on the JS shell does not show performances as bad as what appeared in the Browser app of B2G.

I still have to investigate what make the browser app so different in a benchmark which is mostly running JS code, mostly because the web-based one updates the web page to present the result to the user and has almost 10 MB of extra memory in its run-time.

(1) The lowest limit of maxBytes for running octane is around 80 MB on x64, and around 60 MB on ARM.

Comment 8

[Nicholas Nethercote [inactive]]

Has bug 843733's patch fixed this?

Comment 9

[Nicolas B. Pierron [:nbp]]

As I am unable to reproduce this issue, as the game does not start at all, for the moment I can only assume that it is a duplicate of Bug 843733.  The second patch of it should hopefully land soon (as long as I can garantee that there is no issue with it).

Can you check once it is landed?  Also the DMD seems to be working fine on B2G and to report the memory issues found on shumway test case (when running it on B2G).  So if this does not fix your issue, you should check with the DMD enabled.

Comment 10

[Nicholas Nethercote [inactive]]

Vlad, can you try again?

Comment 11

[Nicholas Nethercote [inactive]]

I'm going to assume that this is effectively a duplicate of bug 843733.