The rendered proposal text has been pulled from https://tc39.es/proposal-resizablearraybuffer/. https://arai-a.github.io/ecma262-compare/?pr=3116 is currently the best option to see the changes.

Thanks for picking this up :)

There's intentionally only a single shell option which controls both options.
This makes testing easier and the test262 tests are also using a single
feature flag for resizable ArrayBuffers and growable SharedArrayBuffers.

Disallow resizable ArrayBuffers for:

• asm.js because it's not designed for resizable buffers.
• DOM bindings because mozilla::dom::TypedArray caches the TypedArrays's length.
• Structured cloning because I haven't yet checked how structured cloning should
  work when resizable ArrayBuffers are used.

Depends on D183317

Change ArrayBufferObject into an abstract base class for the two new
classes FixedLengthArrayBufferObject and ResizableArrayBufferObject.

We need different classes, because resizable ArrayBuffers have slightly different
semantics and also need another reserved slot. Adding another reserved slot to
ArrayBufferObject changes the allocation kind from AllocKind::ARRAYBUFFER4
to AllocKind::ARRAYBUFFER8, which seems unfortunate for the common case of
non-resizable ArrayBuffers.

Depends on D183318

Resizable ArrayBuffers need an additional reserved slot to store the maximum
byte length. Similar to ArrayBufferObject::BYTE_LENGTH_SLOT, this slot is set
to zero when the buffer is detached.

Depends on D183319

Getters for maxByteLength or resizable simply read the corresponding slots.

Depends on D183320

In preparation for actually enabling the ArrayBuffer constructor to create
resizable ArrayBuffers, we need additional functions to pass through the
correct JSClass and adjust the memory reporting to use the correct number of
associated bytes.

Depends on D183321

Update the ArrayBuffer constructor function to create resizable ArrayBuffers.
DataViews and TypedArrays don't yet support resizable ArrayBuffers, so they
throw when a resizable ArrayBuffer is used as the input.

Depends on D183322

Resizing simply adjusts the byte-length slot and sets the memory to
zero if the array is shrunk.

Depends on D183323

Depends on D183324

Similar to part 3, add separate classes for fixed-length and resizable
DataView objects.

Depends on D183325

DataViews which are baked by a resizable ArrayBuffer can get out-of-bounds when
the ArrayBuffer is shrunk. It can later get again in-bounds when the ArrayBuffer
is grown. That means it's no longer possible to directly read the byte-length
and byte-offset from the reserved slots. Instead all accesses need to validate
the ArrayBufferView is still in-bounds. mozilla::Maybe is used to to represent
in-bound and out-of-bounds results.

Depends on D183326

Depends on D183327

Depends on D183328

Similar to part 3, add separate classes for fixed-length and resizable
TypedArray objects.

Depends on D183329

It's easy to add support for resizable typed arrays to branchIfClassIsNotTypedArray,
because the classes are in contiguous memory.

MacroAssembler::typedArrayElementSize is a bit more difficult, at least when
trying to avoid duplicating the detection for both fixed length and resizable
typed array classes.

Depends on D183330

Replace TypedArrayObject with FixedLengthTypedArrayObject for part 18, when
TypedArrayObject::length() gets changed to handle out-of-bounds.

Depends on D183331

Disabled until support gets added in a later patch in this stack.

Depends on D183332

Update all accesses to handle possible out-of-bounds. In some cases the TypedArray
is guaranteed to be a FixedLengthTypedArrayObject, which ensures the accesses are
always in-bounds.

Depends on D183333

Part 14 only disallowed attaching resizable typed arrays in CacheIR, but we
still need to guard the object is also a fixed-length typed array at runtime.

Depends on D183334

Update the step comments and reload the TypedArray length before filling the
TypedArray per the resizable ArrayBuffer proposal.

Depends on D183335

Throw a TypeError for out-of-bounds, but keep returning zero for detached buffers
to match the inlined JIT code.

Depends on D183336

Simply calls PossiblyWrappedTypedArrayLength which throws an error for
out-of-bounds TypedArrays.

Depends on D183338

Part 21 changed the TypedArrayLength to throw for out-of-bounds typed arrays,
but in a handful of cases we actually need to read the typed array length
without throwing an error for out-of-bounds.

Add a separate intrinsic for these cases and update the relevant self-hosted
functions to call TypedArrayLengthZeroOnOutOfBounds.

Depends on D183339

Depends on D183340

Depends on D183341

The ArrayBuffer.prototype.slice update for resizable array buffers was
still missing.

Depends on D183342

Depends on D183343

Part 17 disabled Atomics for resizable buffers. Remove this restriction again.

Inlining Atomics functions for resizable buffers isn't affected by this change.

Depends on D183344

Depends on D183345

Depends on D183346

Depends on D183347

Depends on D183348

Depends on D183349

Depends on D183350

Depends on D183351

This is an initial implementation of the resizable ArrayBuffers proposal. The rendered spec is no longer available at https://tc39.es/proposal-resizablearraybuffer/, instead https://arai-a.github.io/ecma262-compare/?pr=3116 is probably right now the best option to view the changes. This is still missing SpiderMonkey-specific tests, but before starting to write tests I want to make sure the proposed implementation is actually acceptable.

(In reply to André Bargull [:anba] from comment #37)

This is an initial implementation of the resizable ArrayBuffers proposal. The rendered spec is no longer available at https://tc39.es/proposal-resizablearraybuffer/, instead https://arai-a.github.io/ecma262-compare/?pr=3116 is probably right now the best option to view the changes. This is still missing SpiderMonkey-specific tests, but before starting to write tests I want to make sure the proposed implementation is actually acceptable.

I left a bunch of comments on various phabricator revisions, which you probably won't see because it says it won't send out notifications for them since none of them are marked for review yet. I'm not actually sure how to see my comments without looking at each one in turn.

But to summarize, I think the approach is good. Most of my comments were in https://phabricator.services.mozilla.com/D183330. I'd like to hash out the C++ type hierarchy, because it's a mess before your patches and your patches multiply the stuff that's there.

Also, although I'm ok with allocating the max byte length up front, I'm worried about writing to the unused portion (for zeroing). It's pretty easy to imagine someone creating a whole bunch of max-1GB ABs with small initial sizes and then never resizing them, which would generate a lot of pressure (on the TLB, on paging space, etc.) It's certainly safer, but I'm worried that it won't fly. (It would also be nice to rely on demand-zeroed pages from the OS, but that's an optimization of much lesser concern.)

Sorry for the delay. These patches look good overall and the approach makes sense to me.

What's the situation for code outside of SpiderMonkey? Do we need to audit that or add support for resizable buffers?

(In reply to Steve Fink [:sfink] [:s:] from comment #38)

I left a bunch of comments on various phabricator revisions, which you probably won't see because it says it won't send out notifications for them since none of them are marked for review yet. I'm not actually sure how to see my comments without looking at each one in turn.

Thanks! I'll go through the individual commits.

But to summarize, I think the approach is good. Most of my comments were in https://phabricator.services.mozilla.com/D183330. I'd like to hash out the C++ type hierarchy, because it's a mess before your patches and your patches multiply the stuff that's there.

I'll respond there.

Also, although I'm ok with allocating the max byte length up front, I'm worried about writing to the unused portion (for zeroing). It's pretty easy to imagine someone creating a whole bunch of max-1GB ABs with small initial sizes and then never resizing them, which would generate a lot of pressure (on the TLB, on paging space, etc.) It's certainly safer, but I'm worried that it won't fly. (It would also be nice to rely on demand-zeroed pages from the OS, but that's an optimization of much lesser concern.)

We use calloc when creating zeroed buffers, which should be fast when using system allocators (likely implemented using mmap(MAP_ANONYMOUS)), but I don't know if jemalloc's calloc uses the same kind of optimisations which are present in system allocators. If jemalloc's calloc touches every byte on the initial allocation, that's bad for the reasons outlined by you.

(In reply to Jan de Mooij [:jandem] from comment #39)

What's the situation for code outside of SpiderMonkey? Do we need to audit that or add support for resizable buffers?

The current patches are zeroing length (and byteOffset) output-parameters when an ArrayBufferView is out-of-bounds, so existing callers see them as zero-size views, which should be safe. If user-code can be executed to possibly resize the buffer between reading and using the length, existing code should (hopefully) already handle this case, because it's similar to detaching a buffer. mozilla::dom::TypedArray will require changes, so https://phabricator.services.mozilla.com/D183318 for now rejects creating mozilla::dom::TypedArray from resizable TypedArrays. That also means most DOM code won't currently work when resizable TypedArrays are used.

Rename MaxByteLength to avoid confusion with the new maxByteLength slot for
resizable ArrayBuffers.

• Prefer "Limit" instead of "Max" because the latter could be misinterpreted to
  refer to maxByteLength, because it also includes the substring "max".

Depends on D183352

Backed out for causing build bustages in SharedArrayObject.cpp

• Backout link
• Push with failures
• Failure Log
• Failure line: /builds/worker/checkouts/gecko/js/src/vm/SharedArrayObject.cpp(306,13): error: unused function 'IsGrowableSharedArrayBuffer' [-Werror,-Wunused-function]

Backed out for causing mochitest-plain failures on test_bug238987.html.
So far, this only affected Android 7.0.

• Push with failures

• Failure log
  There are also this TV jobs that failed:

• https://treeherder.mozilla.org/logviewer?job_id=444702577&repo=autoland&lineNumber=4363

• https://treeherder.mozilla.org/logviewer?job_id=444700903&repo=autoland&lineNumber=5173

• Backout link

[task 2024-01-26T09:02:48.489Z] 09:02:48     INFO -  TEST-PASS | dom/events/test/test_bug238987.html | |window| should not have got a blur event, target [object HTMLDocument]
[task 2024-01-26T09:02:48.489Z] 09:02:48     INFO -  Buffered messages finished
[task 2024-01-26T09:02:48.489Z] 09:02:48  WARNING -  TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | |window| should not have got a blur event, target [object Window]
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      handleWindowBlur@dom/events/test/test_bug238987.html:90:7
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      EventListener.handleEvent*start@dom/events/test/test_bug238987.html:141:12
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      Async*doTest@dom/events/test/test_bug238987.html:159:19
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      callStackHandler@SimpleTest/SimpleTest.js:285:24
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      EventHandlerNonNull*this.addLoadEvent@SimpleTest/SimpleTest.js:314:7
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      @SimpleTest/SimpleTest.js:1809:15
[task 2024-01-26T09:02:48.490Z] 09:02:48  WARNING -  TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | |window| should not have got a blur event, target [object Window]
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      handleWindowBlur@dom/events/test/test_bug238987.html:90:7
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      EventListener.handleEvent*start@dom/events/test/test_bug238987.html:142:12
[task 2024-01-26T09:02:48.490Z] 09:02:48     INFO -      Async*doTest@dom/events/test/test_bug238987.html:159:19
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      callStackHandler@SimpleTest/SimpleTest.js:285:24
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      EventHandlerNonNull*this.addLoadEvent@SimpleTest/SimpleTest.js:314:7
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      @SimpleTest/SimpleTest.js:1809:15
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -  TEST-PASS | dom/events/test/test_bug238987.html | |window| should not have got a focus event, target [object HTMLDocument]
[task 2024-01-26T09:02:48.491Z] 09:02:48  WARNING -  TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | |window| should not have got a focus event, target [object Window]
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      handleWindowFocus@dom/events/test/test_bug238987.html:63:7
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      EventListener.handleEvent*start@dom/events/test/test_bug238987.html:139:12
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      Async*doTest@dom/events/test/test_bug238987.html:159:19
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      callStackHandler@SimpleTest/SimpleTest.js:285:24
[task 2024-01-26T09:02:48.491Z] 09:02:48     INFO -      EventHandlerNonNull*this.addLoadEvent@SimpleTest/SimpleTest.js:314:7
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -      @SimpleTest/SimpleTest.js:1809:15
[task 2024-01-26T09:02:48.492Z] 09:02:48  WARNING -  TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | |window| should not have got a focus event, target [object Window]
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -      SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -      handleWindowFocus@dom/events/test/test_bug238987.html:63:7
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -      EventListener.handleEvent*start@dom/events/test/test_bug238987.html:140:12
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -      Async*doTest@dom/events/test/test_bug238987.html:159:19
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -      callStackHandler@SimpleTest/SimpleTest.js:285:24
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -      EventHandlerNonNull*this.addLoadEvent@SimpleTest/SimpleTest.js:314:7
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -      @SimpleTest/SimpleTest.js:1809:15
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -  TEST-PASS | dom/events/test/test_bug238987.html | |window| should not have got a focus event, target [object HTMLInputElement], id="i2"
[task 2024-01-26T09:02:48.492Z] 09:02:48     INFO -  TEST-PASS | dom/events/test/test_bug238987.html | Wrong activeElement!
[task 2024-01-26T09:02:48.493Z] 09:02:48  WARNING -  TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | (focus) Forward tabbing, expected [i3], got [i2]
[task 2024-01-26T09:02:48.493Z] 09:02:48     INFO -      SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
<...>

(In reply to Iulian Moraru from comment #46)

Backed out for causing mochitest-plain failures on test_bug238987.html.
So far, this only affected Android 7.0.

These failures seem unrelated to this bug. Intermittent failures for "test_bug238987.html" were previously tracked in bug 1776983, so maybe there's a pre-existing issue with that test.

• Failure log
  There are also this TV jobs that failed:

Thanks, this is indeed an issue with a test added in part 2. The test must only be run in debug-mode, because it uses debug-only features.

https://hg.mozilla.org/mozilla-central/rev/53fad2b43a0b
https://hg.mozilla.org/mozilla-central/rev/49226ab4093e
https://hg.mozilla.org/mozilla-central/rev/fe2a4caa1dd7
https://hg.mozilla.org/mozilla-central/rev/567f67b8e187
https://hg.mozilla.org/mozilla-central/rev/2b7cc2586ca5
https://hg.mozilla.org/mozilla-central/rev/cf831e50329b
https://hg.mozilla.org/mozilla-central/rev/a4808ad0653d
https://hg.mozilla.org/mozilla-central/rev/72fe72f79def
https://hg.mozilla.org/mozilla-central/rev/f4d118cc11eb
https://hg.mozilla.org/mozilla-central/rev/7fd46f4f4dc4
https://hg.mozilla.org/mozilla-central/rev/5568c4f7e127
https://hg.mozilla.org/mozilla-central/rev/2835f49b2bdc
https://hg.mozilla.org/mozilla-central/rev/c04808acc476
https://hg.mozilla.org/mozilla-central/rev/b82a9a84917f
https://hg.mozilla.org/mozilla-central/rev/f8f412e48ae6
https://hg.mozilla.org/mozilla-central/rev/40667536f69f
https://hg.mozilla.org/mozilla-central/rev/9978604b6be7
https://hg.mozilla.org/mozilla-central/rev/4118e5895c1c
https://hg.mozilla.org/mozilla-central/rev/457e09f19fcf
https://hg.mozilla.org/mozilla-central/rev/6ab8d493bddf
https://hg.mozilla.org/mozilla-central/rev/b2f91ee492ee
https://hg.mozilla.org/mozilla-central/rev/a3895c4f05b8
https://hg.mozilla.org/mozilla-central/rev/70abde51cfc3
https://hg.mozilla.org/mozilla-central/rev/6406d024f7e9
https://hg.mozilla.org/mozilla-central/rev/6df23bd678c0
https://hg.mozilla.org/mozilla-central/rev/ef37056db3f7
https://hg.mozilla.org/mozilla-central/rev/ac69b72d508b
https://hg.mozilla.org/mozilla-central/rev/616fce8c2915
https://hg.mozilla.org/mozilla-central/rev/ec958e11736a
https://hg.mozilla.org/mozilla-central/rev/bf7c93fe5eb7
https://hg.mozilla.org/mozilla-central/rev/28f978fb00cb
https://hg.mozilla.org/mozilla-central/rev/bcb108625dff
https://hg.mozilla.org/mozilla-central/rev/d01cb7f0d759
https://hg.mozilla.org/mozilla-central/rev/2bf38170c0e6
https://hg.mozilla.org/mozilla-central/rev/9049b720c9f9
https://hg.mozilla.org/mozilla-central/rev/fce9e7386189

FF124 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/32337

This is mostly just a compatibility data and MDN release note update.