Skip to content

Commit

Permalink
Address mficarra review
Browse files Browse the repository at this point in the history
  • Loading branch information
syg committed Aug 23, 2023
1 parent 9872549 commit b17d725
Showing 1 changed file with 10 additions and 12 deletions.
22 changes: 10 additions & 12 deletions spec.html
Original file line number Diff line number Diff line change
Expand Up @@ -14638,7 +14638,7 @@ <h1>[[OwnPropertyKeys]] ( ): a normal completion containing a List of property k

<emu-clause id="sec-integer-indexed-object-with-buffer-witness-records">
<h1>Integer-Indexed Object With Buffer Witness Records</h1>
<p>A <dfn variants="Integer-Indexed Object With Buffer Witness Records">Integer-Indexed Object With Buffer Witness Record</dfn> 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 SharedArrayBuffers.</p>
<p>An <dfn variants="Integer-Indexed Object With Buffer Witness Records">Integer-Indexed Object With Buffer Witness Record</dfn> 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.</p>
<p>Integer-Indexed Object With Buffer Witness Records have the fields listed in <emu-xref href="#table-integer-indexed-object-with-buffer-witness-record-fields"></emu-xref>.</p>
<emu-table id="table-integer-indexed-object-with-buffer-witness-record-fields" caption="Integer-Indexed Object With Buffer Witness Record Fields">
<table>
Expand Down Expand Up @@ -42757,7 +42757,6 @@ <h1>

<p>The implementation of HostResizeArrayBuffer must conform to the following requirements:</p>
<ul>
<li>The abstract operation must return either NormalCompletion(~handled~), NormalCompletion(~unhandled~), or an throw completion.</li>
<li>The abstract operation does not detach _buffer_.</li>
<li>If the abstract operation completes normally with ~handled~, _buffer_.[[ArrayBufferByteLength]] is _newByteLength_.</li>
</ul>
Expand Down Expand Up @@ -43123,10 +43122,10 @@ <h1>get ArrayBuffer.prototype.maxByteLength</h1>
1. Perform ? RequireInternalSlot(_O_, [[ArrayBufferData]]).
1. If IsSharedArrayBuffer(_O_) is *true*, throw a *TypeError* exception.
1. If IsDetachedBuffer(_O_) is *true*, return *+0*<sub>𝔽</sub>.
1. If IsFixedLengthArrayBuffer(_O_) is *false*, then
1. Let _length_ be _O_.[[ArrayBufferMaxByteLength]].
1. Else,
1. If IsFixedLengthArrayBuffer(_O_) is *true*, then
1. Let _length_ be _O_.[[ArrayBufferByteLength]].
1. Else,
1. Let _length_ be _O_.[[ArrayBufferMaxByteLength]].
1. Return 𝔽(_length_).
</emu-alg>
</emu-clause>
Expand Down Expand Up @@ -43220,8 +43219,8 @@ <h1>Properties of ArrayBuffer Instances</h1>
<h1>Resizable ArrayBuffer Guidelines</h1>
<emu-note>
<p>The following are guidelines for ECMAScript programmers working with resizable ArrayBuffer.</p>
<p>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.</p>
<p>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 1073741824, or 1GiB.</p>
<p>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.</p>
<p>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 (2<sup>30</sup> bytes or 1GiB).</p>
<p>Please note that successfully constructing a resizable ArrayBuffer for a particular maximum size does not guarantee that future resizes will succeed.</p>
</emu-note>

Expand Down Expand Up @@ -43304,21 +43303,20 @@ <h1>
</h1>
<dl class="header">
<dt>description</dt>
<dd>It gives the host an opportunity to perform implementation-defined growing of _buffer_. If the host chooses not to handle resizing of _buffer_, it may return ~unhandled~ for the default behaviour.</dd>
<dd>It gives the host an opportunity to perform implementation-defined growing of _buffer_. If the host chooses not to handle growing of _buffer_, it may return ~unhandled~ for the default behaviour.</dd>
</dl>
<p>The implementation of HostGrowSharedArrayBuffer must conform to the following requirements:</p>
<ul>
<li>The abstract operation must return either NormalCompletion(~handled~), NormalCompletion(~unhandled~), or an throw completion.</li>
<li>If the abstract operation does not complete normally with ~unhandled~, and _newByteLength_ &lt; the current byte length of the _buffer_ or _newByteLength_ > _buffer_.[[ArrayBufferMaxByteLength]], throw a *RangeError* exception.</li>
<li>Let _isLittleEndian_ be the value of the [[LittleEndian]] field of the surrounding agent's Agent Record. If the abstract operation completes normally with ~handled~, a WriteSharedMemory or ReadModifyWriteSharedMemory event whose [[Order]] is ~SeqCst~, [[Payload]] is NumericToRawBytes(~BigUint64~, _newByteLength_, _isLittleEndian_), [[Block]] is _buffer_.[[ArrayBufferByteLengthData]], [[ByteIndex]] is 0, and [[ElementSize]] is 8 is added to the surrounding agent's candidate execution such that racing calls to `SharedArrayBuffer.prototype.grow` are not "lost", i.e. silently do nothing.</li>
</ul>

<p>The default implementation of HostGrowSharedArrayBuffer is to return ~unhandled~.</p>

<emu-note>
<p>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.</p>
<p>This is in contrast with HostResizeArrayBuffer, which is guaranteed that the value of _newByteLength_ is ≥ 0 and ≤ _buffer_.[[ArrayBufferMaxByteLength]].</p>
</emu-note>

<p>The default implementation of HostGrowSharedArrayBuffer is to return ~unhandled~.</p>
</emu-clause>
</emu-clause>

Expand Down Expand Up @@ -43422,7 +43420,7 @@ <h1>SharedArrayBuffer.prototype.grow ( _newLength_ )</h1>
1. If _newByteLength_ &lt; _currentByteLength_ or _newByteLength_ > _O_.[[ArrayBufferMaxByteLength]], throw a *RangeError* exception.
1. Let _byteLengthDelta_ be _newByteLength_ - _currentByteLength_.
1. If it is impossible to create a new Shared Data Block value consisting of _byteLengthDelta_ bytes, throw a *RangeError* exception.
1. NOTE: No new Shared Data Block is constructed and used here. The observable behaviour of growable SharedArrayBuffers is specified by allocating a max-sized Shared Data Block at construction time, and this step is captures the requirement that implementations that run out of memory must throw a *RangeError*.
1. NOTE: No new Shared Data Block is constructed and used here. The observable behaviour of growable SharedArrayBuffers is specified by allocating a max-sized Shared Data Block at construction time, and this step captures the requirement that implementations that run out of memory must throw a *RangeError*.
1. Let _readByteLengthRawBytes_ be AtomicCompareExchangeInSharedBlock(_byteLengthBlock_, 0, 8, _currentByteLengthRawBytes_, _newByteLengthRawBytes_).
1. If ByteListEqual(_readByteLengthRawBytes_, _currentByteLengthRawBytes_) is *true*, return *undefined*.
1. Set _currentByteLengthRawBytes_ to _readByteLengthRawBytes_.
Expand Down

0 comments on commit b17d725

Please sign in to comment.