Skip to content
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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

gibson042
Copy link
Collaborator

Fixes #9

@gibson042 gibson042 requested a review from erights December 25, 2024 04:24
@erights
Copy link
Collaborator

erights commented Dec 26, 2024

How do i see the rendered form of this?

@gibson042 gibson042 force-pushed the gh-9-slicetoimmutable branch 3 times, most recently from d3653db to 8e3eaea Compare December 26, 2024 23:55
Copy link

github-actions bot commented Dec 27, 2024

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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<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.

Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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?

Copy link
Collaborator

@erights erights left a 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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@gibson042 gibson042 force-pushed the gh-9-slicetoimmutable branch from 185e926 to 2dffb91 Compare December 28, 2024 03:19
@gibson042 gibson042 force-pushed the gh-9-slicetoimmutable branch from 2dffb91 to c775957 Compare December 28, 2024 05:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

add .sliceToImmutable?
2 participants