search

tc39 / ecma262

Status, process, and documents for ECMA-262
https://tc39.es/ecma262/
Other
15.08k stars 1.29k forks source link

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

Open mathiasbynens opened 6 years ago

mathiasbynens commented 6 years ago

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 commented 6 years ago

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

littledan commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.