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
