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.

I can reproduce this on Windows 7.

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.

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

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

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)

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

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

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

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.

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?

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.

Why are we marking all singleton objects during an animation?

(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.

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

(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.

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

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)