Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-26 Thread Katelyn Gadd
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

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-26 Thread Till Schneidereit
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

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-26 Thread Mark S. Miller
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

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-26 Thread Filip Pizlo
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

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-26 Thread Jeff Walden
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

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-26 Thread Luke Wagner
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:

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-25 Thread Jeff Walden
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

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-25 Thread Mark S. Miller
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

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-25 Thread Mark S. Miller
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