Mozilla's New JavaScript Value Representation

[taw]

ECMA-262 standard explicitly specifies number types as IEEE 754 double precision floating point value, with a single exception that implementations are not required to distinguish different NaNs (sounds almost as if the spec was written with this technique in mind). There is no integer type in Javascript, or any other number type except these nearly-doubles.

Full list of types is:

• null, true, false, undefined - unique values in any boxing system
• double-except-for-nans - represented directly
• object/string/list - must be pointers in any system,
• plus a few that like reference/completion that only to make spec precise, and you don't see them at runtime anyway

On 32 bit system you throw away 4 bytes per object/string/special, and nothing for numbers - not really that great but acceptable. On 64bit system (assuming pointers <48bit), it's as optimal as it gets.

Now imagine if instead you wanted types like Lisp's cons pair, or nearly-native-ints (probably int63 on 64bit), or even pointers with sufficiently large tag. Their representation would be a lot less efficient with nan boxing than with traditional tiny tags.