839631 - frequent write to canvas combined with typed array allocation triggers out of memory

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Stephan Herhut [:masterofhats]]

Attachment: html file to reproduce the error

When writing to a canvas and allocating large typed arrays in a frequently run (event) loop, the system eventually triggers a js_ReportOutOfMemory, although there should be no more than 2 live objects in the heap (at least from the script). 

To reproduce, load the attached HTML document and click go. The script stops running after a short while.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I can reproduce this on Windows 7.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Just a few notes:
We are doing TOO_MUCH_MALLOC collections here, but they're not collecting anything. If I dump the heap right after the script runs, there are lots of marked Uint8Array objects. After another collection (which cleans everything up) there's only one. I disabled incremental and compartment GC and the problem still happens.

My hunch right now is that this has something to do with bug 789295. It landed in the FF18 timeframe, and it can cause typed arrays to be marked when they otherwise wouldn't. I'll have to figure out some way to check if this is correct or not.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I just tried a 9/25 nightly and it still happens. Maybe I'll try bisecting.

Comment 4

[Andrew McCreight [:mccr8]]

How do typed arrays show in about:memory?  I'm just wondering if this could be related to bug 839548.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

It looks the same as that bug. Here's a sample.

2,660.45 MB (100.0%) -- explicit
├──2,401.52 MB (90.27%) -- window-objects
│  ├──2,221.70 MB (83.51%) -- top(..., id=900)
│  │  ├──2,208.21 MB (83.00%) -- active/window(...)
│  │  │  ├──2,208.06 MB (83.00%) -- js/compartment(...)
│  │  │  │  ├──2,207.55 MB (82.98%) -- objects-extra
│  │  │  │  │  ├──2,207.54 MB (82.98%) ── elements
│  │  │  │  │  └──────0.01 MB (00.00%) ── slots
│  │  │  │  └──────0.52 MB (00.02%) ++ (4 tiny)
│  │  │  └──────0.14 MB (00.01%) ++ (3 tiny)
│  │  └─────13.49 MB (00.51%) ++ cached
│  ├─────96.44 MB (03.62%) ++ (23 tiny)

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Actually, as far as I can tell, this reproduces in 17 as well. I'm not sure bisection is going to work here.

Comment 7

[Loic]

There is clearly a regression since Firefox 16.
In FF18, after ~200 array allocations, the script stops (see the web console).
In FF15, I'm able to run 1k or 2k allocations without the script stops.

Regression range:
m-c
good=2012-06-30
bad=2012-07-01
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f08d285b63b0&tochange=d9d61d199b11

m-i
good=2012-06-29
bad=2012-06-30
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=33bee15f56d0&tochange=37776fc33437

Comment 8

[Alice0775 White]

Regression window(cached m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/a3322674e2c3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629142151
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b3d91c0e323b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629154650
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a3322674e2c3&tochange=b3d91c0e323b

In local build
Last Good: 9933d50de880
First Bad: e8c20d4ba61a
Triggered by:
e8c20d4ba61a	Brian Hackett — Treat canvas invalidations as animation activity for JS heuristics, bug 753630. r=dmandelin

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Thanks for the regression range. That makes a lot of sense. We're detecting an animation, so we mark all singleton objects during the GC. Big typed arrays are singletons, so they're all getting marked.

At the very least, we need to stop doing this when we're running out of memory.

Comment 10

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

My understanding is that we use a singleton type for big typed arrays as an optimization for Emscripten code. If so, we probably should expect there to be only one or two of these at any given time. If so, we could stop doing the singleton thing after the first one is created.

Brian, Alon, does that make sense? Are there other places where this stuff is used?

Comment 11

[Alon Zakai (:azakai)]

In emscripten there will be at most 2 *big* global singleton typed arrays. However there are a few smaller global singleton typed arrays used for various things.

Comment 12

[Andreas Gal :gal]

Why are we marking all singleton objects during an animation?

Comment 13

[Brian Hackett [Laid off!]]

(In reply to Andreas Gal :gal from comment #12)
> Why are we marking all singleton objects during an animation?

TI requires this.  During animations we don't sweep jitcode to avoid jank, which means we need to keep type constraints around.  The constraints aren't marked by the GC, and can refer to type objects and singleton objects.  This should be simple to fix after bug 804676 --- that bug will remove the transient type sets that can refer to singleton objects, so we can do normal GC cycles without needing to discard jitcode as well.

Comment 15

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

We got another report of this. Brian, do you still think this would be simple to fix? Bug 804676 is closed now.

Comment 16

[Brian Hackett [Laid off!]]

(In reply to PTO Bill McCloskey (:billm) (away until 9/9) from comment #15)
> We got another report of this. Brian, do you still think this would be
> simple to fix? Bug 804676 is closed now.

The actual removal of analyzeTypes moved to bug 864928, which landed recently.  The analysis data does not contain temporary untraced type sets anymore, so what we could do now is keep the analysis data around and just trace things as normal, including the tracing done on type sets attached to scripts and type objects.

Comment 17

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I believe this should be fixed by bug 932982. Unassigning myself in any case.

Comment 18

[Guilherme Lima]

After 1 minute running the testcase, about:memory shows

183.83 MB (46.94%) -- top(https://bug839631.bugzilla.mozilla.org/attachment.cgi?id=711960, id=48)
│  │  ├──183.73 MB (46.91%) -- active/window(https://bug839631.bugzilla.mozilla.org/attachment.cgi?id=711960)
│  │  │  ├──181.31 MB (46.29%) -- js-compartment(https://bug839631.bugzilla.mozilla.org/attachment.cgi?id=711960)
│  │  │  │  ├──181.29 MB (46.29%) -- classes
│  │  │  │  │  ├──181.12 MB (46.25%) -- class(ArrayBuffer)
│  │  │  │  │  │  ├──181.12 MB (46.25%) -- objects
│  │  │  │  │  │  │  ├──181.12 MB (46.25%) ── malloc-heap/elements/non-asm.js
│  │  │  │  │  │  │  └────0.00 MB (00.00%) ── gc-heap
│  │  │  │  │  │  └────0.00 MB (00.00%) ++ shapes/gc-heap
│  │  │  │  │  └────0.17 MB (00.04%) ++ (2 tiny)
│  │  │  │  └────0.02 MB (00.01%) ++ (2 tiny)
│  │  │  └────2.42 MB (00.62%) -- (4 tiny)
│  │  │       ├──2.41 MB (00.62%) ++ layout
│  │  │       ├──0.01 MB (00.00%) ++ dom
│  │  │       ├──0.00 MB (00.00%) ── property-tables
│  │  │       └──0.00 MB (00.00%) ── style-sheets
│  │  └────0.11 MB (00.03%) ++ js-zone(0x16911800)