In the past 'throw' statements have caused a deopt for the enclosing
function in v8 and spidermonkey. I think they still do in some
scenarios. I would assume that if a statement is able to throw the
enclosing function must have unwind logic and it could potentially
suppress inlining as well
On Thu, Feb 26, 2015 at 6:48 PM, Katelyn Gadd k...@luminance.org wrote:
In the past 'throw' statements have caused a deopt for the enclosing
function in v8 and spidermonkey. I think they still do in some
scenarios. I would assume that if a statement is able to throw the
enclosing function
Jeff?
On Thu, Feb 26, 2015 at 9:48 AM, Katelyn Gadd k...@luminance.org wrote:
In the past 'throw' statements have caused a deopt for the enclosing
function in v8 and spidermonkey. I think they still do in some
scenarios. I would assume that if a statement is able to throw the
enclosing
Seems like a bug. You can just profile whether the exceptional path was ever
taken; if it wasn't then speculate that accesses are in-bounds. Boom, you have
a fast in-bounds check and the optimizing JIT doesn't have to know anything
about what happens on out-of-bounds (i.e. it could throw
On 02/26/2015 09:54 AM, Mark S. Miller wrote:
Jeff?
To be completely honest, I can't answer this. My message was merely to pass
along the sentiments of others, observed elsewhere, not previously communicated
to this list. I personally don't understand what we're doing at a low level
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 jwalden...@mit.edu wrote:
And expanding scope slightly: IntegerIndexedElementGet -- get -- throws a
TypeError if the relevant typed array is detached, rather than just returning
|undefined| as the computed value. I understand there are also significant
complaints about this, for similar reasons.
Jeff
Again, I don't understand this. Why would it make the normal case more
expensive. The underlying detachment test must be there regardless, and the
only difference in behavior is what happens after that test fails.
On Wed, Feb 25, 2015 at 5:05 PM, Jeff Walden jwalden...@mit.edu wrote:
And
Somewhere there's obviously got to be a bounds check, in order to not
overwrite memory outside the array. Why does the requirement that the
failure of this bounds check cause a TypeError make the inbounds case any
more expensive? The specified difference in behavior is only what happens
following
9 matches
Mail list logo