> Sorry I meant type "tags" in the sense of modifying the language syntax to have required type annotations.
There are already multiple types in JavaScript, and this already affects performance; for example "+" is defined for both numbers and strings. All JavaScript engines handle this in the same way, more or less. You start out with a "baseline JIT" that does not make assumptions about the types of objects and has type-check-and-dispatch on operations like "+". These type checks record the types of objects that have flowed through each point. Once enough types have flowed through so that we can reasonably predict the types, we recompile the function to assume that the same type (for example, number) goes through, which enables greater optimizations. You then hoist type guards up (or eliminate them if you can prove them never taken) so that you deoptimize and bail out.
Value objects don't change this overall picture, they just add more types.
All of this, however, is irrelevant to asm.js. With an ahead-of-time optimizing compiler, we know what the types are beforehand via the asm.js spec. So there are no type guards inserted at all, and none of this is an issue. For example, NaN-boxing is not used in the Firefox asm.js compiler (OdinMonkey). We know which values are doubles and which are integers, so we need no runtime guards or type tests at all.
I was responding specifically to the comment that if v8 team continues optimizing in response to asm.js as they have been, perhaps there is no need for NaCL (or asm.js). I don't think that will ever be true.
There are already multiple types in JavaScript, and this already affects performance; for example "+" is defined for both numbers and strings. All JavaScript engines handle this in the same way, more or less. You start out with a "baseline JIT" that does not make assumptions about the types of objects and has type-check-and-dispatch on operations like "+". These type checks record the types of objects that have flowed through each point. Once enough types have flowed through so that we can reasonably predict the types, we recompile the function to assume that the same type (for example, number) goes through, which enables greater optimizations. You then hoist type guards up (or eliminate them if you can prove them never taken) so that you deoptimize and bail out.
Value objects don't change this overall picture, they just add more types.
All of this, however, is irrelevant to asm.js. With an ahead-of-time optimizing compiler, we know what the types are beforehand via the asm.js spec. So there are no type guards inserted at all, and none of this is an issue. For example, NaN-boxing is not used in the Firefox asm.js compiler (OdinMonkey). We know which values are doubles and which are integers, so we need no runtime guards or type tests at all.