I got two beefs. The first is ergonomic. I want phased workloads like parsing + BCE and JIT compiling to be completely infallible. The allocation pattern of compilers is a series of many small allocations. I'd like to just allocate a huge buffer inside a LifoAlloc-like allocator in the beginning and call it a day. That shouldn't impact 32bit address space fragmentation. Checking false/null returns everywhere really puts a crimp in my evening.
The second is complexity and software correctness. I think this is what Jan alludes to in the initial email. Correct OOM handling goes beyond simple null/false checking. In a complex VM like ours, it often means rolling your own "bespoke, single-use STM" (Jim Blandy's words). This makes the code complex and hard to understand. Let me give some concrete cases from the code I touch. Rolling back Debugger internal state when JIT frames fail (like OOMing during OSR) is a giant pain to get right. Relatedly, code now has to deal with weirdness and cannot rely on invariants. See the nonsense in [1] to deal with iterating scope chains during an OOM event. This kind of corner-case handling could *obscure* legitimate bugs. Modestly large allocations can and should be checked for failure. However, many places in a virtual machine really should not bend over backwards to deal with fallible allocation. [1] https://dxr.mozilla.org/mozilla-central/source/js/src/vm/ScopeObject.cpp#1455-1470 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 > -- shu _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
