In gecko, "large" allocations (anything that is under site control) are supposed to be fallible and have at least some kind of sane fallback path. This is not universally true currently but it is the goal.
Small allocations in gecko are fatal (crashy), and so I don't think there's any point in making small allocation failure in the JS engine any less fatal now because of gecko. However, in either a future-gecko world or something more like servo, I do think that our goal should be to have separate environments per DOM window and only tear those down rather than the whole process. That assumes that we can track and recover per-window environments cleanly enough that this wouldn't cause giant memory leaks. The process boundary currently used by chrome is a pretty expensive abstraction for that behavior in terms of memory and cross-window messaging overhead. --BDS On Thu, Apr 21, 2016 at 4:44 PM, Luke Wagner <[email protected]> wrote: > 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 > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
