Can TypedArray properties be partitioned better?

[gibson042]

TypedArray Exotic Objects internal methods apply distinct treatment to properties based upon which class they fall into:

• in-range integer index (as observed by IsValidIntegerIndex(O, index)): corresponds with a TypedArray element
• out-of-range integer index, or canonical numeric string that is not an integer index (e.g., "-0"/"-1"/"1.2"/"NaN" or String(2**53) = "9007199254740992"): disallowed, but "silently" (e.g., [[Set]] returns true)
• other string or symbol: no special treatment; effectively a normal property

https://output.jsbin.com/fisifehuxa attempts to illustrate these categories, including existing failures by Hermes, JavaScriptCore, and QuickJS to conform with various edge cases. It also demonstrates the behavior of proposal-immutable-arraybuffer to use visible rather than silent rejection when the backing ArrayBuffer is immutable.

The categories don't really make sense... integer indexes ought to be special, even when they are out of range, but that status should be visible. And even more importantly, there's no reason to apply that special treatment to canonical numeric strings that are not integer indexes. So if possible (read: web compatible), changing those would be good for the spec and good for developers, such that

• silent no-ops are replaced with noisy ones, exposed in Reflect functions and in strict-mode exceptions, and/or
• the canonical numeric status of a string becomes irrelevant; only those that are integer indexes are subject to the special treatment.

Category	Examples	Specification	Nonconformance	Ideal
in-range integer index	"0"	mutation	JSC Reflect.set(ta, key, value, taDescendant) mutates ta	no change
other integer index	String(2**53 - 1)	silent no-op	Hermes mutates TA-descendant Hermes treats index ≥ 2**32 - 1 as non-canonical (and mutates TA) JSC assignment mutates TA-descendant when index < 2**32 - 1	rejection
other canonical numeric string	"-0", "-1", "1.2", "NaN"	silent no-op	Hermes mutates QuickJS treats key "NaN" as non-canonical (and mutates)	mutation as non-special key in the following category
other string	"", "1.20"	mutation	none found	mutation (no change)
symbol	Symbol()	mutation	none found	mutation (no change)

[anba]

Canonical numeric strings allow non-integers to ensure all Number inputs are handled by the TypedArray instance and don't perform prototype lookups. This helps for example when JIT compiling, because all Number inputs allow to stay in JIT code.

Here's the relevant assembly for x64 in SpiderMonkey when converting a double-typed Number to an (intptr_t-typed) TypedArray index:

; Input: %xmm0
; Output: %rax
vcvttsd2si %xmm0, %rax
xorpd      %xmm15, %xmm15
cvtsi2sd   %rax, %xmm15
vucomisd   %xmm15, %xmm0
jp         .L0
je         .L1
.set .L0
movq       $-1, %rax
.set .L1

The assembly converts non-integer indices to -1, which is then treated like any other out-of-bounds value.

index in typedArray is then compiled to:

; Convert double index to intptr in %rax using the above asm sequence.

; TypedArray: %rcx
; TypedArray length: %rdx
movq       0x20(%rcx), %rdx

; Test: index u< length
; Output: %rcx
xorl       %ecx, %ecx
cmpq       %rdx, %rax
setb       %cl

i32[index] = 0 is compiled to:

; Convert double index to intptr in %rax using the above asm sequence.

; Load TypedArray length
movq       0x20(%rcx), %rdx

; Load TypedArray elements
movq       0x30(%rcx), %rcx

; Store zero into Int32Array with bounds-check.
cmpq       %rdx, %rax
jae        .L0
movl       $0x0, 0x0(%rcx,%rax,4)
.set .L0

(I'm omitting the case when loading from a TypedArray, because it involves SpiderMonkey's Value boxing format, which should be irrelevant here.)

As you can see, in both cases there are no deoptimisation bailouts necessary and we can stay in JIT code all the time.

Here are some relevant issues:

1. Automated regression reports when support for negative integer indices was messed up: https://bugzilla.mozilla.org/show_bug.cgi?id=1942628, https://bugzilla.mozilla.org/show_bug.cgi?id=1942775, https://bugzilla.mozilla.org/show_bug.cgi?id=1535031.
2. Non-integer indices into TypedArrays: https://bugzilla.mozilla.org/show_bug.cgi?id=1515620, https://bugzilla.mozilla.org/show_bug.cgi?id=1526315, Channel3.getSample computes non-integer typed array index, leading to recompilation loop in Firefox torch2424/wasmboy#216.

I don't recall why "-0" was made special.

[gibson042]

@anba Thanks very much for the detail—I can definitely see value in being able to handle any property key that is provided as a Number value without prototype chain traversal, and I think the performance regression issues relating to negative indexes for neighboring pixels indicate that, regardless of druthers, such inputs are expected for at least [[Get]]s and should continue to have guaranteed undefined results. So while it might be possible to replace silent no-op writes with strict-mode-noisy rejections, non-integer-index canonical numeric string keys like "-1" remain a relevant category that should be preserved.

But your explanation has clarified for me why the spec has its current shape, and I'd like to incorporate its insight into editorial text, probably expanding the first paragraph in TypedArray Exotic Objects to describe the nature of special handling and how it affects not just integer index property keys but all canonical numeric strings, which theirselves form a superset of the values corresponding to the output of ToPropertyKey with Number input (which is a strict superset only because it includes "-0").

[anba]

I don't recall why "-0" was made special.

Found the issue where the special casing for "-0" was added: https://tc39.es/archives/bugzilla/2830/