Closed Bug 1135141 Opened 7 years ago Closed 7 years ago

jsapi-tests fails with JS_GC_ZEAL=2,10

Categories

(Core :: JavaScript: GC, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla39
Tracking Status
firefox39 --- fixed

People

(Reporter: terrence, Assigned: terrence)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

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.
Attachment #8567224 - Flags: review?(jcoppeard)
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.
Attachment #8567224 - Flags: review?(jcoppeard) → review+
Here's the patch, but it doesn't fix all the failures.
Attachment #8567867 - Flags: review?(terrence)
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.
Attachment #8567868 - Flags: review?(terrence)
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.
Attachment #8567867 - Flags: review?(terrence) → review+
Attachment #8567868 - Flags: review?(terrence) → review+
(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.
Attachment #8568201 - Flags: review?(jcoppeard)
Attachment #8567224 - Flags: checkin+
Attachment #8568201 - Flags: review?(jcoppeard) → review+
https://hg.mozilla.org/mozilla-central/rev/60192399a18e
Assignee: nobody → terrence
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Duplicate of this bug: 1049440
You need to log in before you can comment on or make changes to this bug.