Integer index vs. array index in [[OwnPropertyKeys]]() on TypedArrays

[mathiasbynens]

Per spec, a TypedArray length is limited to 2**53-1, i.e. the greatest possible integer index, because of step 3 in https://tc39.github.io/ecma262/#sec-typedarray-length.

However, in practice all engines except JavaScriptCore don’t even support creating a TypedArray with a length equal to the greatest possible array index + 1, i.e. 2**32-1. Note that I couldn’t test the actual JavaScriptCore behavior as my machine (128 GB RAM) ran out of memory.

$ eshost -e 'new Uint8Array(2**32-1)'
#### Chakra
RangeError: Invalid offset/length when creating typed array

#### V8 --harmony
RangeError: Invalid typed array length: 4294967295

#### V8
RangeError: Invalid typed array length: 4294967295

#### JavaScriptCore
Error: Out of memory

#### SpiderMonkey
RangeError: invalid array length

This means that the use of “integer index” over “array index” in https://tc39.github.io/ecma262/#sec-integer-indexed-exotic-objects-ownpropertykeys is not currently supported by engines, either.

We could reduce the unimplemented parts of the spec to a smaller subset that is consistent with existing OwnPropertyKeys implementations for other kinds of objects.

See #1242 and #1243.

[ChALkeR]

Some earlier part of the conversation at IRC: Gist (as IRC logs seem broken).
Also, tc39/test262#1580 is related.

[ChALkeR]

Some earlier part of the conversation at IRC: Gist (as IRC logs seem broken).
Also, tc39/test262#1580 is related.

[littledan]

I think the use of a larger maximum here was a deliberate, forward-looking design decision. Given that JSC seems to support larger sizes already, what is the motivation for considering a change?

[littledan]

I think the use of a larger maximum here was a deliberate, forward-looking design decision. Given that JSC seems to support larger sizes already, what is the motivation for considering a change?

[mathiasbynens]

Given that JSC seems to support larger sizes already

I’m not sure about that. As stated, new Uint8Array(2**32-1) ran out of memory on a machine with 128 GB RAM.

what is the motivation for considering a change

The fact that engines currently don’t implement this. Having the spec contradict reality is not useful.

[mathiasbynens]

Given that JSC seems to support larger sizes already

I’m not sure about that. As stated, new Uint8Array(2**32-1) ran out of memory on a machine with 128 GB RAM.

what is the motivation for considering a change

The fact that engines currently don’t implement this. Having the spec contradict reality is not useful.

[littledan]

BTW ES6 made the whole ToLength change to support large TypedArrays. It was a rather large change that ran into some web compat fixes that were needed.

[littledan]

BTW ES6 made the whole ToLength change to support large TypedArrays. It was a rather large change that ran into some web compat fixes that were needed.

[anba]

Just because engines currently seem to restrict ArrayBuffer allocation to 2GB doesn't mean that we should put that as the maximum into the spec.

[anba]

Just because engines currently seem to restrict ArrayBuffer allocation to 2GB doesn't mean that we should put that as the maximum into the spec.