Non-extensibility of Typed Arrays

Filip Pizlo fpizlo at
Fri Aug 30 12:46:15 PDT 2013

On Aug 30, 2013, at 12:31 PM, Brendan Eich <brendan at> wrote:

> Thanks for the reply, I'll let SM and V8 peeps speak for themselves (they retired my SM number ;-).
>> Filip Pizlo <mailto:fpizlo at>
>> August 30, 2013 10:41 AM
>> On Aug 30, 2013, at 9:28 AM, Brendan Eich <brendan at <mailto:brendan at>> wrote:
>>> Hi,
>>>> Filip Pizlo <mailto:fpizlo at>
>>>> August 28, 2013 11:01 PM
>>>> Here's the part that gets me, though: what is the value of disallowing named properties on typed arrays?  Who does this help?
>>> You've heard about symmetry with struct types (ES6), right? Those do not want expandos. We could break symmetry but at some cost. Too small to worry about? Outweighed by benefits?
>> It's a fair point.  I don't see where it would break semantics but I'll try to do a thought experiment to see if it makes things confusing or inconvenient to the programmer.  Whether or not I care depends on the answers to the following questions:
>> 1) Is the purpose to simplify programming by allowing you to add static typing?
> No, we put a stake through that cold heart.
>> 2) Are we trying to help JITs?
> Yes, I think so (SM retirement makes this easy for me to say ;-). Even excluding type inference as done in SpiderMonkey, just using PICs, structs over against objects can help JITs avoid boxing values, same as typed arrays do compared to Arrays.

This isn't really a win, at least not for us, anyway.  We don't "box" values in the sense of allocating stuff in the heap; we only tag them.  The tagging operations are just too darn cheap to worry about getting rid of them.  For example, int untagging is basically free.  Double untagging is not quite free but our double array inference (for normal JS arrays) is too darn good - you'd have to try quite hard to find a case where using a Float64Array gives you a real win over a JS array into which you only stored doubles.  Once exception is that our double array inference for normal JS arrays fails if you store NaN.  Our current philosophy towards that is "oh well" - it's not clear that this arises enough that we should care.

> Sometimes you want a product of different types, not a vector of same-typed elements. Typed arrays were designed so you would alias two views, crazypants. Structs put on sanepants. Just making sure the use-case has clear motivation here.

OK - by "sanepants" do you mean that there is no weirdo aliasing?  Going back to my example of field 'a' aliasing field 'b' - is it possible?

> If so, then the JIT wins implemented today among multiple engines for typed array element loads and stores will almost certainly be wanted for struct field traffic too.

I think you're being too generous to the typed array optimizations.  Vanilla JS arrays are catching up, or have already caught up and surpassed, depending on how you look at it.

It sure is tempting to add type thingies to help JITs but I think we're quickly approaching a world where adding primitive types to JS will be a bit like marking your Java methods final in the mistaken belief that it will unlock some extra devirtualization, or marking your variables 'register' in C thinking that this will make your code sooooper fast.

>> 3) Do we just want a sensible way of mapping to binary data?  (For both DOM and C-to-JS compilers)
> Yes, and don't forget the GPU as well ("DOM" doesn't take that in).

Right!  I totally buy the native mapping story for struct types.  I just don't buy the performance story. ;-)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list