Normative: Introduce ArrayBuffer.prototype.sliceToImmutable #21
Conversation
|
How do i see the rendered form of this? |
gibson042
force-pushed
the
gh-9-slicetoimmutable
branch
3 times, most recently
from
d3653db to
8e3eaea
Compare
|
The rendered spec for this PR is available at https://tc39.es/proposal-immutable-arraybuffer/pr/21. |
spec.emu
Outdated
|
|
||
| <emu-clause id="sec-data-blocks" number="2.9"> | ||
| <h1>Data Blocks</h1> | ||
| <p>A data block that resides in memory that can be referenced from multiple agents concurrently is designated a <dfn variants="Shared Data Blocks">Shared Data Block</dfn>. A Shared Data Block has an identity (for the purposes of equality testing Shared Data Block values) that is <em>address-free</em>: it is tied not to the virtual addresses the block is mapped to in any process, but to the set of locations in memory that the block represents. Two data blocks are equal only if the sets of the locations they contain are equal; otherwise, they are not equal<ins>.</ins> <del>and the intersection of the sets of locations they contain is empty</del> <ins>The intersection of the sets of locations contained by two non-equal data blocks may be non-empty only when both data blocks are immutable and one is a strict subset of the other</ins>. Finally, Shared Data Blocks can be distinguished from Data Blocks.</p> |
There was a problem hiding this comment.
| <p>A data block that resides in memory that can be referenced from multiple agents concurrently is designated a <dfn variants="Shared Data Blocks">Shared Data Block</dfn>. A Shared Data Block has an identity (for the purposes of equality testing Shared Data Block values) that is <em>address-free</em>: it is tied not to the virtual addresses the block is mapped to in any process, but to the set of locations in memory that the block represents. Two data blocks are equal only if the sets of the locations they contain are equal; otherwise, they are not equal<ins>.</ins> <del>and the intersection of the sets of locations they contain is empty</del> <ins>The intersection of the sets of locations contained by two non-equal data blocks may be non-empty only when both data blocks are immutable and one is a strict subset of the other</ins>. Finally, Shared Data Blocks can be distinguished from Data Blocks.</p> | |
| <p>A data block that resides in memory that can be referenced from multiple agents concurrently is designated a <dfn variants="Shared Data Blocks">Shared Data Block</dfn>. A Shared Data Block has an identity (for the purposes of equality testing Shared Data Block values) that is <em>address-free</em>: it is tied not to the virtual addresses the block is mapped to in any process, but to the set of locations in memory that the block represents. Two data blocks are equal only if the sets of the locations they contain are equal; otherwise, they are not equal<ins>.</ins> <del>and the intersection of the sets of locations they contain is empty</del> <ins>The intersection of the sets of locations contained by two non-equal data blocks may be non-empty only when both data blocks are immutable</ins>. Finally, Shared Data Blocks can be distinguished from Data Blocks.</p> |
The "and one is a strict subset of the other" is clearly wrong because you could have two overlapping slices of a common parent.
There was a problem hiding this comment.
for the purposes of equality testing Shared Data Block values
Where?
There was a problem hiding this comment.
The "and one is a strict subset of the other" is clearly wrong because you could have two overlapping slices of a common parent.
Hmm, good point. But I still want text to point out that overlapping memory locations are not acceptable without an immutable common parent (e.g., a 16-byte data block at location X vs. a 16-byte data block at location X + 4). Please look over the latest text.
for the purposes of equality testing Shared Data Block values
Where?
I don't know; that's existing text that I don't want to touch here.
There was a problem hiding this comment.
Given @waldemarhorwat's point (which we agreed with at plenary) that the spec not state more than equivalence to buf.slice(s,e).toImmutable(), I don't think we need to touch the notion of shared locations at all. Let the spec imply that buf.sliceToImmutable(s,e) makes copies, just as buf.slice(s,e).toImmutable() would. When buf is also immutable, an implementation can share (i.e., "zero-copy") as an implementation optimization. But there's no reason for the spec to bless this beyond a non-normative note.
Then the "Shared Data Blocks" in the spec can remain as they are, and would continue to apply only to SABs.
Waddaya think?
There was a problem hiding this comment.
I'm satisfied that your spec text does preserve exactly that equivalence, and you already have the text that should be moved into a non-normative note. Thus, I think your spec text works as is, once you revert and revision to the discussion of "shared locations". We are not using those "shared locations".
spec.emu
Outdated
| </h1> | ||
| <dl class="header"> | ||
| <dt>description</dt> | ||
| <dd>It is used to create an immutable ArrayBuffer (i.e., an ArrayBuffer with a an [[ArrayBufferIsImmutable]] slot) with contents from _fromBlock_. Because neither the identity of a Data Block nor the set of locations in memory represented by it are observable, implementations may implement this operation without allocating new Data Block memory locations when _fromBlock_ is the value of the [[ArrayBufferData]] slot for some other immutable ArrayBuffer (and therefore already immutable) and _count_ = _byteLength_.</dd> |
There was a problem hiding this comment.
| <dd>It is used to create an immutable ArrayBuffer (i.e., an ArrayBuffer with a an [[ArrayBufferIsImmutable]] slot) with contents from _fromBlock_. Because neither the identity of a Data Block nor the set of locations in memory represented by it are observable, implementations may implement this operation without allocating new Data Block memory locations when _fromBlock_ is the value of the [[ArrayBufferData]] slot for some other immutable ArrayBuffer (and therefore already immutable) and _count_ = _byteLength_.</dd> | |
| <dd>It is used to create an immutable ArrayBuffer (i.e., an ArrayBuffer with a an [[ArrayBufferIsImmutable]] slot) with contents from _fromBlock_.``` | |
| Move the text starting with "Because" into a non-normative note, to make clearer that it is just an observation about what optimizations are unobservable. |
gibson042
force-pushed
the
gh-9-slicetoimmutable
branch
from
185e926 to
2dffb91
Compare
gibson042
force-pushed
the
gh-9-slicetoimmutable
branch
from
2dffb91 to
c775957
Compare
| <emu-clause id="sec-ecmascript-data-types-and-values" number="6"> | ||
| <h1>ECMAScript Data Types and Values</h1> | ||
|
|
||
| <emu-clause id="sec-data-blocks" number="2.9"> | ||
| <h1>Data Blocks</h1> | ||
| <p>A data block that resides in memory that can be referenced from multiple agents concurrently is designated a <dfn variants="Shared Data Blocks">Shared Data Block</dfn>. A Shared Data Block has an identity (for the purposes of equality testing Shared Data Block values) that is <em>address-free</em>: it is tied not to the virtual addresses the block is mapped to in any process, but to the set of locations in memory that the block represents. Two data blocks are equal only if the sets of the locations they contain are equal; otherwise, they are not equal<ins>.</ins> <del>and the intersection of the sets of locations they contain is empty</del> <ins>The intersection of the sets of locations contained by two non-equal data blocks may be non-empty only when both data blocks are immutable and either one is a strict subset of the other or both are strict subsets of an immutable common parent</ins>. Finally, Shared Data Blocks can be distinguished from Data Blocks.</p> | ||
| </emu-clause> | ||
| </emu-clause> |
There was a problem hiding this comment.
@gibson042 , do you agree that these revisions to this paragraph do not actually serve any purpose, since the immutable sharing that seems to motivate it is not actually part of the semantic state, but rather "only" a non-observable optimization opportunity?
There was a problem hiding this comment.
No, I don't agree. The current text in ECMA-262 that "Two data blocks are equal only if the sets of the locations they contain are equal; otherwise, they are not equal and the intersection of the sets of locations they contain is empty" is in a paragraph that starts by defining Shared Data Block but is not limited to them, and seems to actually prohibit the zero-copy optimization that we're hoping for—if it remains untouched, then I think the "implementations may implement this operation without allocating new memory locations when fromBlock is the value of the [[ArrayBufferData]] slot for some other immutable ArrayBuffer (and therefore already immutable) and count = byteLength" note would need to be removed.
But the tweak to that paragraph could be much smaller if it is indeed intended to have limited application:
Two
data blocksShared Data Blocks are equal only if the sets of the locations they contain are equal; otherwise, they are not equal and the intersection of the sets of locations they contain is empty.
Fixes #9