-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: Introduce ArrayBuffer.prototype.sliceToImmutable #21
base: main
Are you sure you want to change the base?
Conversation
How do i see the rendered form of this? |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for the purposes of equality testing Shared Data Block values
Where?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
185e926
to
2dffb91
Compare
2dffb91
to
c775957
Compare
Fixes #9