We seem to get OOM errors when we GC too frequently? Something here smells very fishy. Jon's build also fails, but in different tests than mine, so this must be a race of some sort. My failures appear to be out of PossiblyOOM, our test code; however, when I print the actual OOM_ static values, they are not such that they could be failing. Upshot, I've got no idea what's going on yet.

As discussed on IRC, the issue here is that, first, off-thread sweeping is running constantly because of the constant GC's and this is resulting in massive, massive fragmentation of the heap. Secondly, in debug builds, compacting keeps the set of empty arenas around for a full GC cycle so that accessing unrelocated pointers will crash. When we run a second GC immediately after the first LAST_DITCH, this clears the saved, free arenas and the program can finish easily within an 8MiB heap (although still 8x more space than non-zeal because of non-object fragmentation). If, alternatively, we stop background sweeping by waiting on all GCs the fragmentation goes away entirely. As a halfway point, this patch waits on background sweeping after a LAST_DITCH GC. Jon is going to post a patch that additionally throws away empty arenas on LAST_DITCH GC, which should largely solve the problem. That said, the fragmentation issue does remain, although at a lower level.

Comment on attachment 8567224 [details] [diff] [review] finish_sweeping_automatically_on_last_ditch-v0.diff Review of attachment 8567224 [details] [diff] [review]: ----------------------------------------------------------------- Great. It occurs to me that we probably want this for the MEM_PRESSURE reason too.

Here's the patch, but it doesn't fix all the failures.

Here's a patch to fix a crash in the jsapi-test harness if a test fails due to OOM when creating a global. It makes createGlobal() only update the 'global' member if it succeeds.

In particular testCloneScript fails reliably for me. Disabling compacting doesn't help, but disabling background sweeping makes it pass. testGCOutOfMemory also fails in zeal mode 2, and bug 1049440 is already open for that.

(In reply to Jon Coppeard (:jonco) from comment #5) > In particular testCloneScript fails reliably for me. > > Disabling compacting doesn't help, but disabling background sweeping makes > it pass. The reason we OOM with a high zeal frequency is that the number of allocations between GCs is much much lower than the number of things we can fit on a page. Thus, we necessarily generate a handful of fragmented and unrecoverable pages if we don't allow the mutator to continue allocating from the same page(s) immediately after the GC. I think the right solution here is to wait for background sweeping if we are doing a zeal-induced GC. > testGCOutOfMemory also fails in zeal mode 2, and bug 1049440 is already open > for that. I had forgotten about that bug, or I would have re-used it.

As discussed and as commented.

(In reply to Terrence Cole [:terrence] from comment #7) > https://hg.mozilla.org/integration/mozilla-inbound/rev/7332e3a8953a Oh, this has a green try run, too: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f8cf97b7ae07

https://hg.mozilla.org/integration/mozilla-inbound/rev/554bb824751a https://hg.mozilla.org/integration/mozilla-inbound/rev/512332b90f15

https://hg.mozilla.org/mozilla-central/rev/512332b90f15 https://hg.mozilla.org/mozilla-central/rev/554bb824751a