Due to 32-bit + fragmentation, even "modest" allocations of 300mb can regularly fail, so it seems important to allow apps to gracefully handle these situations and put up some UI that informs the user. You can also consider cases where the allocation failure doesn't mean the whole app is dead, just the app can't open a file, in which case the app can live on (just not open that file). In both these cases, if we do the "return false without exception pending" behavior, we may leave the application in a seriously borked state because all stack control-flow invariants have been broken. This seems like it would lead to bizarre or even dangerous web app behavior.
A pretty reasonable compromise, which Jason suggested [1], is to only throw for "large" allocations. But I think to avoid putting apps into this corrupt state, we should treat small-allocation-OOM as a Stop Slow Script. Even for Stop Slow Script, though, I've thought for a while that, when we stop a script, we should prevent execution in that window. We make a pretty weak attempt to do this today, by killing timeouts and maybe a few other things, but it's still totally possible to run code in a window that's been stop-scripted. This is ancient behavior; with compartments, it seems like we could actually achieve a hard invariant (the hard case being reentrant nesting). But I guess that's an orthogonal concern. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=865960#c20 On Thu, Apr 21, 2016 at 3:21 PM, Jason Orendorff <[email protected]> wrote: >> Dealing with OOM everywhere is complicated enough, but I think the >>>> exception part makes it even more difficult to get right. >>>> >>> > ...Incidentally, I still think OOM shouldn't be catchable, just as a matter > of sane language behavior. It's too likely to re-fail during catch/finally > blocks. > > Luke, we changed this for gamedev users, right? Do we still need it? Could > we offer an asynchronous OOM-reporting mechanism instead? > > -j > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
