Note that a while back I added a mechanism where you can easily ban script from ever running again in a compartment - see [1] for a usage example.
So this should be a trivial (and probably worthwhile) patch. [1] https://hg.mozilla.org/mozilla-central/file/10f66b316457/dom/base/nsGlobalWindow.cpp#l2755 On Thu, Apr 21, 2016 at 1: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
