804492 - SpiderMonkey should stop trying to recover from most OOM

Status: RESOLVED DUPLICATE of bug 606198

(Core :: JavaScript Engine, enhancement)

Description

[Jesse Ruderman]

* What little testing of OOM handling we've done has shown that many paths in the JS engine do not recover correctly.  A significant fraction of these bugs affect memory safety.  (See bug 471528, bug 687256, and bug 624094.)

* Most of the browser (along with some pieces of SpiderMonkey, such as YARR and the IonMonkey compiler) do not attempt to recover from small-allocation failures.  So when Firefox is out of memory, it's probably going to crash eventually anyway.

* Chrome JS is impossible to analyze if a web page can cause its execution to just halt, at any point, by leaving just the right amount of memory available.

I think SpiderMonkey should

- Try to recover in a few cases (strings and arrays)
  - Perhaps with the rule that it must be an exception rather than a terminate()
  - But notify the embedding, so it can bail if security-relevant chrome JS OOMs

- Avoid starting big computations (e.g. parsing or compiling) when low on memory

- Just crash on OOM "by default" and wherever it's not obvious how to recover

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The GC heap allocates memory in large (1MB I think) chunks, not small bits, so it's not clear to me what this would mean in practice.

CCing some people who may be interested.

Comment 2

[Andrew McCreight [:mccr8]]

The JS engine uses two kinds of allocation, the chunks for the GC, but also normal jemalloc allocations.

Comment 3

[Nicholas Nethercote [inactive]]

This is well-trodden ground, see bug 606198.  The short version is:  Brendan never much liked the idea.