We extend the
SharedArrayBuffer constructors to take an additional maximum byte length, which would construct dynamically resizable and growable array buffers, respectively. In addition, a
transfer method is added to the
The abstract operation DetachArrayBuffer takes argument arrayBuffer and optional argument key. It performs the following steps when called:
Detaching an ArrayBuffer instance disassociates the
No operations defined by this specification use the DetachArrayBuffer abstract operation. However, an ECMAScript host or implementation may define such operations.
The abstract operation AllocateArrayBuffer takes arguments constructor
and byteLength. It is used to create an ArrayBuffer object. It performs the following steps when called:
ArrayBuffer function is called with argument length, the following steps are taken:
ArrayBuffer[@@species] is an
The value of the
The abstract operation AllocateSharedArrayBuffer takes arguments constructor
and byteLength. It is used to create a SharedArrayBuffer object. It performs the following steps when called:
SharedArrayBuffer function is called with optional arguments length and options, the following steps are taken:
SharedArrayBuffer.prototype.byteLength is an
The [[OwnPropertyKeys]] internal method of an
The abstract operation IsValidIntegerIndex takes arguments O, getBufferByteLength, and index. It performs the following steps when called:
The abstract operation ValidateTypedArray takes argument O. It performs the following steps when called:
This function is not generic. The
The abstract operation SetTypedArrayFromTypedArray takes arguments target (a TypedArray object), targetOffset (a non-negative
The abstract operation InitializeTypedArrayFromTypedArray takes arguments O (a TypedArray object) and srcArray (a TypedArray object). It performs the following steps when called:
The abstract operation InitializeTypedArrayFromArrayBuffer takes arguments O (a TypedArray object), buffer (an ArrayBuffer object), byteOffset (an
The abstract operation GetViewValue takes arguments view, requestIndex, isLittleEndian, and type. It is used by functions on DataView instances to retrieve values from the view's buffer. It performs the following steps when called:
The abstract operation SetViewValue takes arguments view, requestIndex, isLittleEndian, type, and value. It is used by functions on DataView instances to store values into the view's buffer. It performs the following steps when called:
DataView function is called with at least one argument buffer, the following steps are taken:
DataView.prototype.byteLength is an
DataView.prototype.byteOffset is an
The abstract operation ValidateAtomicAccess takes arguments typedArray and requestIndex. It performs the following steps when called:
The following are guidelines for ECMAScript programmers working with resizable ArrayBuffer and growable SharedArrayBuffer.
We recommend that programs be tested in their deployment environments where possible. The amount of available physical memory differ greatly between hardware devices. Similarly, virtual memory subsystems also differ greatly between hardware devices as well as operating systems. An application that runs without out-of-memory errors on a 64-bit desktop web browser could run out of memory on a 32-bit mobile web browser.
When choosing a value for the
"maxByteLength" option for resizable ArrayBuffer and growable SharedArrayBuffer, we recommend that the smallest possible size for the application be chosen. We recommend that
"maxByteLength" does not exceed 1073741824, or 1GiB.
Please note that successfully constructing a ResizableArrayBuffer or a growable SharedArrayBuffer for a particular maximum size does not guarantee that future resizes and grows will succeed.
The following are guidelines for ECMAScript implementers implementing resizable ArrayBuffer.
Resizable ArrayBuffer can be implemented as copying upon resize, as in-place growth via reserving virtual memory up front, or as a combination of both for different values of the
"maxByteLength" ≥ 1GiB to 1.5GiB. This is to reduce the likelihood a single application can exhaust the virtual memory address space and to reduce interoperability risks.
If a host does not have virtual memory, such as those running on embedded devices without an MMU, or if a host only implements resizing by copying, it may accept any
"maxByteLength" option. However, we recommend a
The following are guidelines for ECMAScript implementers implementing growable SharedArrayBuffer.
We recommend growable SharedArrayBuffer be implemented as in-place growth via reserving virtual memory up front.
Because grow operations can be concurrent with memory accesses on a growable SharedArrayBuffer, the constraints of the
Grown memory must appear zeroed from the moment of its creation, including to any racy concurrent accesses. This can be accomplished via zero-filled-on-demand virtual memory pages, or careful synchronization if manually zeroing memory.
In practice it is difficult to implement growable SharedArrayBuffer by copying on hosts that do not have virtual memory, such as those running on embedded devices without an MMU. Memory usage behaviour of growable SharedArrayBuffers on such hosts may significantly differ from that of hosts with virtual memory. Such hosts should clearly communicate memory usage expectations to users.
Uses of [[ByteLength]] on
Uses of [[ArrayBufferByteLength]] on buffer objects that may be growable SharedArrayBuffers are replaced with calls to