On Fri, Apr 22, 2016 at 3:16 AM, Jan de Mooij wrote:
>
> I think in 'ancient' SpiderMonkey, we used to deal with OOM by returning
> null/false. Other exceptions were reported to the JSContext.
>
> Then we changed this: ReportOutOfMemory now throws the "out of memory"
> string. This allowed scripts
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, N
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 al
3 matches
Mail list logo
