When expecting a positive integer...

Brendan Eich brendan at mozilla.com
Tue Apr 9 11:37:57 PDT 2013

Kevin Gadd wrote:
> Fancy behavior for out of range indices on Typed Arrays seems like it 
> could be more trouble than it's worth. Ideally, you want something 
> that can be cheaply implemented on native targets like x86, if not 
> implemented for free because it's something the runtime has to do 
> anyway. Returning undefined seems like it would definitely imply a 
> performance penalty, or at least make work a lot harder for type 
> inference/analysis engines, because now you have to prove that all 
> indices are in range.

We already handle this in TI in SpiderMonkey, and in asm.js AOT 
compilation in OdinMonkey. True, we didn't want to change Typed Arrays 
incompatibly, so we made the best of it, but IIRC it wasn't a big deal.

Mainly, we have to face the problem of backward compatibility. If we 
could make all int arrays return 0 not undefined, ditto for float arrays 
viz. NaN, that would be even better for performance.

> Clamping is reasonable

No, it makes all negative indexes alias 0. This is bad for SFI-enforcing 
compilers (Emscripten, Mandreel, PNaCl).

> , but not necessarily what people might expect. Throwing at least does 
> not suffer from the type information problem that undefined does,

Right, and (Allen points out this may have been missed by the Khronos 
editors) typed arrays based on WebIDL index getter/setters require 
throwing. No browser impl that I can test does this, though.

> though I'm sure it still poses issues for JITs - same 'prove all 
> indices are in range' problem to eliminate the bounds check. I could 
> see wrapping being an acceptable choice as well, since that's sort of 
> 'native' semantics.

No, again -- unsafe.

> Firefox appears to return undefined for out of range typed array 
> elements; can someone comment on whether Spidermonkey is easily able 
> to achieve this and whether it hurts the JIT and/or gathering of type 
> information? Would some other behavior be faster? Chrome appears to do 
> this too currently.
Safari too. Differences abound: using Math.pow(2,32) or above as an 
index makes an expando in V8 and JSC. JSC allows named expandos (a.foo = 
42). Proto-indexed properties shine through for out of bounds indexes.

Working to nail these down to be as efficient and safe as possible...

> People really want typed arrays to be fast, so consider that the 
> context for my comments here. :)



More information about the es-discuss mailing list