Sorry if there was any confusion earlier, but throw-on-OOB semantics is
easier from an AOT/asm.js-compilation POV. Ideally, typed arrays would
throw on all OOB, but I realize that isn't web compatible at this point.
On Wed, Feb 25, 2015 at 6:40 PM, Jeff Walden wrote:
> Currently, the behavior o
ArrayBuffer.transfer provides a coarser granularity than the proposed
ArrayBuffer.prototype.discard in bug 855669. Page-level madvise(MADV_DONTNEED)
is the type of thing you'd want if you were implementing a malloc heap
(jemalloc being an example). OTOH, ArrayBuffer.transfer also allows you to
FWIW, "constellation" is a term that some of us have been using for a while (at
least in Mozilla) for a concept that seems to match "Vat". For example, in the
context of:
- when we could have separate task queues on separate threads (as an
unobservable impl detail to improve responsiveness):
It seems to me that we *must* have Math.clz perform ToUint32() on its input.
Otherwise (if ToInt32() is used), even if the expression is written "Math.clz(x
>>> 0)", asm.js/type-inference won't be able to optimize away the <0 branch
since the ToInt32() in the semantics of Math.clz will convert
Just to be sure, do you agree that both the {lo, hi}-returning API and the
magic-property API should both be able to achieve equivalent performance on a
JS engine that has specifically added and optimized these int64 builtins? I
think this is true.
Assuming so, the reason to prefer the rather
5 matches
Mail list logo
