1440145 - Kill tab on uncaught JS OOMs

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Steve Fink [:sfink] [:s:]]

We were discussing (for the nth time) on IRC how to handle OOMs. There seems to be no disagreement that handling large-allocation OOMs is useful. But we appear to be unlikely to recover from small-allocation OOMs; we'll just get more and more errors of various sorts.

I wanted to get a bug on file to document our current thinking, and I'll seed it with a proposal to intentionally kill tabs that trigger small uncaught OOMs. "Kill" here includes being able to free all JS memory associated with the tab and display to the user the crashed tab dialog or preferably something tailored to mention memory.

Comment 1

[Steve Fink [:sfink] [:s:]]

It is of course possible that the tab triggering a small OOM is not the tab using up gobs of memory, and a potentially worthwhile followup would be to change behavior based on the total memory associated with the tab.

Comment 2

[Nicholas Nethercote [inactive]]

Small OOMs currently trigger a process abort. Are you suggesting we instead have fallback code that kills a tab without killing its process? Sounds hard to get right, and if we're heading in the direction of more content processes, is it worthwhile?

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

No, in JS it doesn't oom and kill the process, it fails the allocation (and thus the random JS operation).  You'll see "JavaScript error: , line 0: uncaught exception: out of memory" on stderr, etc.  See GCRuntime::tryNewTenuredThing() and Allocate(), etc.

I ran into this because I had a 12GB content process in a cycle of trying to allocate stuff and failing (including failing allocating 40 bytes), throwing those errors.  I should note that it appeared to get into this state because physical ram was pretty exhausted (32GB) and swap was using quite a bit (most of 16GB IIRC).  However, the allocation failures continued after killing a different 5GB Content Process, reducing physical ram use to ~80%.

More content processes will eventually make this less likely, to a degree (if this happens on phys/swap exhaustion it can still occur, and with higher ram use perhaps sooner - if that's the case, the oom is based on total usage, not using in one process).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Last I checked, OOM in _JS_ could happen to us running out of SpiderMonkey heap, which could happen way before we were actaully OOM depending on what runtime was involved and how it was set up.

Comment 5

[Nicholas Nethercote [inactive]]

So is this bug specifically only about handling small OOMs within SpiderMonkey?

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Changing title to make it clearer

Comment 7

[Paul Bone [:pbone] (PTO until 14/8/2025)]

I'm adding the MemShrink whiteboard flag, if a memory-hungry tab is killed in this way, then firefox will use less memory.  Depending on the user's need for low memory / tabs that arn't killed this can be considered MemShrink IMHO.  Nevertheless it's definitely in the "memory conscious" theme.

Comment 8

[Paul Bone [:pbone] (PTO until 14/8/2025)]

Whoops. I should have read the bug's history and seen that erahm already removed this.