Very interesting to see experience reports counter to my intuition. If looked at from the UX perspective, indeed we should attempt to gracefully handle OOM since the entirety of JavaScript is optional for a page. The last point is debatable in today's web though.
On Fri, Apr 22, 2016 at 3:20 AM, Nicolas B. Pierron < [email protected]> wrote: > On 04/21/2016 09:05 PM, Shu-yu Guo wrote: > >> 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. >> > > We have been on this path with IonMonkey, and I honestly find that this is > a not good practice to have an infallible allocator, especially if you > don't want to cause a browser crash and properly handle OOMs as we try in > IonMonkey. > > The reason why I think we should properly handle OOMs in IonMonkey, is > because this is not part of the mandatory pool of allocation request by the > Script. Thus, the user script should not see these OOMs, as it is > technically not responsible for them. > > The problem then, is that we have to armor any loop which has boundaries > controled by any user inputs. If the user input can be made as large as > possible, then whatever ballast space you take, it can be overflow. I > think, as this is occasional this is much more miss-leading than having a > pattern being repeated over and over. > > I tried to suggest better approaches in Bug 1244824 [1], but the best I > can come up is a way to emulate exception handling, but the pit-falls are > worse. So, if we were to have a static analysis to ensure that we do not > have any destructor to execute while leaving a scope, then I guess we could > emulate exception this way. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1244824 > > -- > Nicolas B. Pierron > > _______________________________________________ > 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
