An Integer-Indexed Object With Buffer Witness Record is a Record value used to encapsulate an Integer-Indexed object along with a cached byte length of the viewed buffer. It is used to help ensure there is a single shared memory read event of the byte length data block when the viewed buffer is a growable SharedArrayBuffer.
+Integer-Indexed Object With Buffer Witness Records have the fields listed in
| + Field Name + | ++ Value + | ++ Meaning + | +
|---|---|---|
| + [[Object]] + | ++ an Integer-Indexed exotic object + | ++ The Integer-Indexed exotic object whose buffer's byte length is loaded. + | +
| + [[CachedBufferByteLength]] + | ++ a non-negative integer or ~detached~ + | ++ The byte length of the object's [[ViewedArrayBuffer]] when the Record was created. + | +
This operation always appears to succeed, but it has no effect when attempting to write past the end of a TypedArray or to a TypedArray which is backed by a detached ArrayBuffer.
+ +This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This function is not generic. The *this* value must be an object with a [[TypedArrayName]] internal slot.
@@ -40629,8 +40792,8 @@This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
This method is not generic. The *this* value must be an object with a [[TypedArrayName]] internal slot.
@@ -40954,8 +41129,8 @@This is a distinct method that implements the same algorithm as `Array.prototype.toLocaleString` as defined in
This method is not generic. ValidateTypedArray is applied to the *this* value prior to evaluating the algorithm. If its result is an abrupt completion that exception is thrown instead of evaluating the algorithm.
+This is a distinct method that implements the same algorithm as `Array.prototype.toLocaleString` as defined in
This method is not generic. ValidateTypedArray is called with the *this* value and ~seq-cst~ as arguments prior to evaluating the algorithm. If its result is an abrupt completion that exception is thrown instead of evaluating the algorithm.
If the ECMAScript implementation includes the ECMA-402 Internationalization API this method is based upon the algorithm for `Array.prototype.toLocaleString` that is in the ECMA-402 specification.
This method performs the following steps when called:
This method performs the following steps when called:
This method performs the following steps when called:
A fixed-length ArrayBuffer is an ArrayBuffer whose byte length cannot change after creation.
+A resizable ArrayBuffer is an ArrayBuffer whose byte length may change after creation via calls to
The kind of ArrayBuffer object that is created depends on the arguments passed to
Detaching an ArrayBuffer instance disassociates the Data Block used as its backing store from the instance and sets the byte length of the buffer to 0. No operations defined by this specification use the DetachArrayBuffer abstract operation. However, an ECMAScript host or implementation may define such operations.
+Detaching an ArrayBuffer instance disassociates the Data Block used as its backing store from the instance and sets the byte length of the buffer to 0.
The implementation of HostResizeArrayBuffer must conform to the following requirements:
+The default implementation of HostResizeArrayBuffer is to return NormalCompletion(~unhandled~).
+This function performs the following steps when called:
The value of the *"name"* property of this function is *"get [Symbol.species]"*.
ArrayBuffer prototype methods normally use their *this* value's constructor to create a derived object. However, a subclass constructor may over-ride that default behaviour by redefining its @@species property.
+The initial value of `ArrayBuffer.prototype.constructor` is %ArrayBuffer%.
+`ArrayBuffer.prototype.maxByteLength` is an accessor property whose set accessor function is *undefined*. Its get accessor function performs the following steps when called:
+`ArrayBuffer.prototype.resizable` is an accessor property whose set accessor function is *undefined*. Its get accessor function performs the following steps when called:
+This method performs the following steps when called:
+This method performs the following steps when called:
@@ -42820,11 +43164,14 @@ArrayBuffer instances inherit properties from the ArrayBuffer prototype object. ArrayBuffer instances each have an [[ArrayBufferData]] internal slot, an [[ArrayBufferByteLength]] internal slot, and an [[ArrayBufferDetachKey]] internal slot.
+ArrayBuffer instances inherit properties from the ArrayBuffer prototype object. ArrayBuffer instances each have an [[ArrayBufferData]] internal slot, an [[ArrayBufferByteLength]] internal slot, and an [[ArrayBufferDetachKey]] internal slot. ArrayBuffer instances which are resizable each have an [[ArrayBufferMaxByteLength]] internal slot.
ArrayBuffer instances whose [[ArrayBufferData]] is *null* are considered to be detached and all operators to access or modify data contained in the ArrayBuffer instance will fail.
ArrayBuffer instances whose [[ArrayBufferDetachKey]] is set to a value other than *undefined* need to have all DetachArrayBuffer calls passing that same "detach key" as an argument, otherwise a TypeError will result. This internal slot is only ever set by certain embedding environments, not by algorithms in this specification.
The following are guidelines for ECMAScript programmers working with resizable ArrayBuffer.
+We recommend that programs be tested in their deployment environments where possible. The amount of available physical memory differs 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, we recommend that the smallest possible size for the application be chosen. We recommend that *"maxByteLength"* does not exceed 1,073,741,824 (230 bytes or 1GiB).
+Please note that successfully constructing a resizable ArrayBuffer for a particular maximum size does not guarantee that future resizes 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 constructor's *"maxByteLength"* option.
+If a host is multi-tenanted (i.e. it runs many ECMAScript applications simultaneously), such as a web browser, and its implementations choose to implement in-place growth by reserving virtual memory, we recommend that both 32-bit and 64-bit implementations throw for values of *"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 risk.
+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
A fixed-length SharedArrayBuffer is a SharedArrayBuffer whose byte length cannot change after creation.
+A growable SharedArrayBuffer is a SharedArrayBuffer whose byte length may increase after creation via calls to
The kind of SharedArrayBuffer object that is created depends on the arguments passed to
The implementation of HostGrowSharedArrayBuffer must conform to the following requirements:
+The second requirement above is intentionally vague about how or when the current byte length of _buffer_ is read. Because the byte length must be updated via an atomic read-modify-write operation on the underlying hardware, architectures that use load-link/store-conditional or load-exclusive/store-exclusive instruction pairs may wish to keep the paired instructions close in the instruction stream. As such, SharedArrayBuffer.prototype.grow itself does not perform bounds checking on _newByteLength_ before calling HostGrowSharedArrayBuffer, nor is there a requirement on when the current byte length is read.
+This is in contrast with HostResizeArrayBuffer, which is guaranteed that the value of _newByteLength_ is ≥ 0 and ≤ _buffer_.[[ArrayBufferMaxByteLength]].
+The default implementation of HostGrowSharedArrayBuffer is to return NormalCompletion(~unhandled~).
+This function performs the following steps when called:
The initial value of `SharedArrayBuffer.prototype.constructor` is %SharedArrayBuffer%.
+This method performs the following steps when called:
+Spurious failures of the compare-exchange to update the length are prohibited. If the bounds checking for the new length passes and the implementation is not out of memory, a ReadModifyWriteSharedMemory event (i.e. a successful compare-exchange) is always added into the candidate execution.
+Parallel calls to SharedArrayBuffer.prototype.grow are totally ordered. For example, consider two racing calls: `sab.grow(10)` and `sab.grow(20)`. One of the two calls is guaranteed to win the race. The call to `sab.grow(10)` will never shrink `sab` even if `sab.grow(20)` happened first; in that case it will instead throw a RangeError.
+`SharedArrayBuffer.prototype.growable` is an accessor property whose set accessor function is *undefined*. Its get accessor function performs the following steps when called:
+`SharedArrayBuffer.prototype.maxByteLength` is an accessor property whose set accessor function is *undefined*. Its get accessor function performs the following steps when called:
+This method performs the following steps when called:
@@ -42976,7 +43447,7 @@SharedArrayBuffer instances inherit properties from the SharedArrayBuffer prototype object. SharedArrayBuffer instances each have an [[ArrayBufferData]] internal slot and an [[ArrayBufferByteLength]] internal slot.
+SharedArrayBuffer instances inherit properties from the SharedArrayBuffer prototype object. SharedArrayBuffer instances each have an [[ArrayBufferData]] internal slot. SharedArrayBuffer instances which are not growable each have an [[ArrayBufferByteLength]] internal slot. SharedArrayBuffer instances which are growable each have an [[ArrayBufferByteLengthData]] internal slot and an [[ArrayBufferMaxByteLength]] internal slot.
SharedArrayBuffer instances, unlike ArrayBuffer instances, are never detached.
The following are guidelines for ECMAScript programmers working with 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 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 growable SharedArrayBuffer for a particular maximum size does not guarantee that future grows will succeed.
+Not all loads of a growable SharedArrayBuffer's length are synchronizing ~seq-cst~ loads. Loads of the length that are for bounds-checking of an integer-indexed property access, e.g. `u8[idx]`, are not synchronizing. In general, in the absence of explicit synchronization, one property access being in-bound does not imply a subsequent property access in the same agent is also in-bound. In contrast, explicit loads of the length via the `length` and `byteLength` getters on SharedArrayBuffer, %TypedArray%.prototype, and DataView.prototype are synchronizing. Loads of the length that are performed by built-in methods to check if a TypedArray is entirely out-of-bounds are also synchronizing.
+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 happen in parallel with memory accesses on a growable SharedArrayBuffer, the constraints of the memory model require that even unordered accesses do not "tear" (bits of their values will not be mixed). In practice, this means the underlying data block of a growable SharedArrayBuffer cannot be grown by being copied without stopping the world. We do not recommend stopping the world as an implementation strategy because it introduces a serialization point and is slow.
+Grown memory must appear zeroed from the moment of its creation, including to any racy accesses in parallel. This can be accomplished via zero-filled-on-demand virtual memory pages, or careful synchronization if manually zeroing memory.
+Integer-indexed property access on TypedArray views of growable SharedArrayBuffers is intended to be optimizable similarly to access on TypedArray views of non-growable SharedArrayBuffers, because integer-indexed property loads on are not synchronizing on the underlying buffer's length (see programmer guidelines above). For example, bounds checks for property accesses may still be hoisted out of loops.
+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.
+A DataView With Buffer Witness Record is a Record value used to encapsulate a DataView along with a cached byte length of the viewed buffer. It is used to help ensure there is a single shared memory read event of the byte length data block when the viewed buffer is a growable SharedArrayBuffers.
+DataView With Buffer Witness Records have the fields listed in
| + Field Name + | ++ Value + | ++ Meaning + | +
|---|---|---|
| + [[Object]] + | ++ a DataView + | ++ The DataView object whose buffer's byte length is loaded. + | +
| + [[CachedBufferByteLength]] + | ++ a non-negative integer or ~detached~ + | ++ The byte length of the object's [[ViewedArrayBuffer]] when the Record was created. + | +
This function performs the following steps when called:
This function performs the following steps when called:
This function performs the following steps when called:
This function notifies some agents that are sleeping in the wait queue.
It performs the following steps when called:
HostEnsureCanCompileStrings(...)
HostFinalizeImportMeta(...)
HostGetImportMetaProperties(...)
+HostGrowSharedArrayBuffer(...)
HostHasSourceTextAvailable(...)
HostLoadImportedModule(...)
HostMakeJobCallback(...)
HostPromiseRejectionTracker(...)
+HostResizeArrayBuffer(...)
InitializeHostDefinedRealm(...)