Open Bug 1317960 Opened 3 years ago Updated 1 year ago

Unity WebGL consuming too much memory, causing 'Out of memory' error

Categories

(Core :: DOM: Core & HTML, defect, P3)

50 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: microeyes07, Unassigned)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(3 files)

Attached image merge_file_11.jpg
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

Steps to reproduce:

1. Launch firefox, open URL http://beta.unity3d.com/jonas/AngryBots/  and let it download.
2. Open Task Manager add-on(https://addons.mozilla.org/en-US/firefox/addon/task-manager/) and observe memory. (In my system its 600+ MB)
3. Now hit refresh(via button on browser or F5), and as soon as browser refresh page & start downloading content again, for some time, memory rises(in my case, memory increased to 800+MB). Let game download again.
4. Now, memory consumption reduced to 400+MB again, which is normal.
5. As soon as game starts again, refresh page again. This time, while still downloading game, the memory consumption is more that as compared to Step#3 (in my case 1,000+MB). At this point of time, i am getting Out of memory error from browser.


Actual results:

1. Browser is getting out of memory, when memory exceeding a threshold (threshold differs from system to system).


Expected results:

1. Memory should not increase progressively and consume only as much as first launch.
Blocks: 1317967
Blocks: 1317986
No longer blocks: 1317986
See Also: → 1317986
Component: Untriaged → Canvas: WebGL
Product: Firefox → Core
Could you attach the information from about:memory?
Flags: needinfo?(microeyes07)
Whiteboard: [gfx-noted]
Please find attachment memory-report_2016Nov17.zip . The issue reproducable when refreshing page and I took some memory shots while refreshing page.
Flags: needinfo?(microeyes07) → needinfo?(howareyou322)
The following is the diff from attachment 8811686 [details].
I saw there was additional 658 MB memory usage from app side.

Reporter, are you able to simplify the test case?

│  │  │  ├──-658.83 MB (132.92%) -- js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │  │  │  ├──-658.16 MB (132.78%) -- classes
│  │  │  │  │  ├──-572.59 MB (115.52%) -- class(ArrayBuffer)/objects
│  │  │  │  │  │  ├──-572.59 MB (115.52%) -- malloc-heap/elements
│  │  │  │  │  │  │  ├──-512.00 MB (103.30%) ── asm.js [2] [-]
Flags: needinfo?(howareyou322) → needinfo?(microeyes07)
@Peter, What do you mean by 'simplify test case'? Do you want me to create another smaller size app for debugging?
> @Peter, What do you mean by 'simplify test case'? Do you want me to create
> another smaller size app for debugging?
So far I don't think this is necessary.

Stabir, I just tried to reproduce this in my machine and found the following memory report.
You could see total 600 MB+ memory usage by AngryBots and half of them were used by a detached windows(before refresh one). Therefore, I would say this is related to GC/CC timing. I would recommend you to use about:memory to capture memory because I sometime see wrong number reported from task manager.
 

│  │    ├──314.16 MB (12.06%) -- detached
│  │    │  ├──312.77 MB (12.00%) -- window([system])
│  │    │  │  ├──312.77 MB (12.00%) -- js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │    │  │  │  ├──312.33 MB (11.99%) -- classes
│  │    │  │  │  │  ├──286.30 MB (10.99%) -- class(ArrayBuffer)/objects
│  │    │  │  │  │  │  ├──256.00 MB (09.83%) ── non-heap/elements/asm.js
│  │    │  │  │  │  │  ├───30.30 MB (01.16%) ── malloc-heap/elements/normal
│  │    │  │  │  │  │  └────0.00 MB (00.00%) ── gc-heap
│  │    │  │  │  │  └───26.04 MB (01.00%) ++ (9 tiny)
│  │    │  │  │  └────0.43 MB (00.02%) ++ (6 tiny)
│  │    │  │  └────0.00 MB (00.00%) ++ dom
│  │    │  └────1.39 MB (00.05%) ++ (2 tiny)
│  │    └───28.82 MB (01.11%) ++ ghost
│  ├────340.39 MB (13.06%) -- top(http://beta.unity3d.com/jonas/AngryBots/, id=2147484856)/active/window(http://beta.unity3d.com/jonas/AngryBots/)
│  │    ├──339.33 MB (13.02%) -- js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │    │  ├──336.59 MB (12.92%) -- classes
│  │    │  │  ├──291.23 MB (11.18%) -- class(ArrayBuffer)/objects
│  │    │  │  │  ├──256.00 MB (09.83%) ── non-heap/elements/asm.js
│  │    │  │  │  ├───35.22 MB (01.35%) ── malloc-heap/elements/normal
│  │    │  │  │  └────0.00 MB (00.00%) ── gc-heap(In reply to Satbir Singh from comment #4)
Flags: needinfo?(microeyes07)
@Peter: Can you give me an idea on how to capture about:memory repeatedly while page is getting refresh? From default about:memory, i'll have to use button "Measure and save", which takes time, to measure & pops-up a save dialog box.
(In reply to Satbir Singh from comment #6)
> @Peter: Can you give me an idea on how to capture about:memory repeatedly
> while page is getting refresh? From default about:memory, i'll have to use
> button "Measure and save", which takes time, to measure & pops-up a save
> dialog box.

How about open two tab for about:memory? And then run "measure" before demo and after demo?
The following were memory report for AngryBots. It looks like this app could occupy up to 600 MB. During refresh, the detached windows still kept alive for a while and the total windows object occupied around 1000 MB. I didn't see anything we could do in graphic side.

├──339.96 MB (64.43%) -- window-objects
│  ├──338.94 MB (64.24%) -- top(http://beta.unity3d.com/jonas/AngryBots/, id=2147483649)
│  │  ├──331.53 MB (62.83%) ++ active/window(http://beta.unity3d.com/jonas/AngryBots/)
│  │  └────7.42 MB (01.41%) ++ (2 tiny)

├──674.14 MB (68.24%) -- window-objects
│  ├──673.21 MB (68.15%) -- top(http://beta.unity3d.com/jonas/AngryBots/, id=2147483649)
│  │  ├──665.70 MB (67.39%) -- active/window(http://beta.unity3d.com/jonas/AngryBots/)
│  │  │  ├──665.42 MB (67.36%) ++ js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │  │  └────0.29 MB (00.03%) ++ (4 tiny)


├──1,042.34 MB (70.26%) -- window-objects
│  ├────658.91 MB (44.41%) -- top(none)/detached/window([system])
│  │    ├──658.83 MB (44.41%) -- js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │    │  ├──658.16 MB (44.36%) ++ classes
│  │    │  └────0.67 MB (00.05%) ++ (5 tiny)
│  │    └────0.08 MB (00.01%) ++ (2 tiny)
│  ├────382.58 MB (25.79%) ++ top(http://beta.unity3d.com/jonas/AngryBots/, id=2147483649)
Possible related to DOM?
Component: Canvas: WebGL → DOM
Hi Boris, do you think this is something related to GC timing? Any more ideas? Thank you.
Flags: needinfo?(bzbarsky)
Hi,
Any progress on this bug?
> Hi Boris, do you think this is something related to GC timing?

If you take a page that's using 400MB, then unload it and load another page that's using 400MB, then you will be using 800MB until a GC happens and the now-unloaded page's objects are collected.  Is that what you were asking?  ;)
Flags: needinfo?(bzbarsky)
Luke, have you seen anything like this before? It seems like reloading is causing multiple copies of the asm.js arraybuffer to be in memory simultaneously but we're not forcing a GC. Andrew McCreight thinks we have some mechanism that should force a GC here.
Flags: needinfo?(luke)
Andrew's right; we have a callback:
  https://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h#l6200
that we call if a large allocation fails (viz., for ArrayBuffers):
  http://searchfox.org/mozilla-central/source/js/src/vm/Runtime.cpp#832
and this callback triggers the low-memory pressure event which should perform a synchronous GC/CC/GC (which, because of the low-memory event, should nuke everything except active documents).

One thing suspicious-looking in comment 9 is the "top(none)/detached/window([system])".  Last time I saw one of these there was some legitimate leak that was keeping the window alive which, transitively, keeps the big expensive old ArrayBuffers around.  Perhaps we could provide instructions for collecting a CC dump?
Flags: needinfo?(luke)
Summary: Unity WebGL taking consuming too much memory, causing 'Out of memory' error → Unity WebGL consuming too much memory, causing 'Out of memory' error
Andrew said he'd try to reproduce and see where/if we're leaking.
Flags: needinfo?(continuation)
The callback in comment 15 might be going wrong here. I'm not really familiar enough with it to investigate, I think. Sorry for the long delay here.
Flags: needinfo?(continuation)
Priority: -- → P3
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.