Normative: Introduce ArrayBuffer.prototype.sliceToImmutable

[gibson042]

Fixes #9

[erights]

How do i see the rendered form of this?

[github-actions]

The rendered spec for this PR is available at https://tc39.es/proposal-immutable-arraybuffer/pr/21.

[erights]

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.

[erights]

for the purposes of equality testing Shared Data Block values

Where?

[gibson042]

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.

[erights]

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?

[erights]

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".

[erights]

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.

[gibson042]

Done.

[erights]

@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?

[gibson042]

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 blocks Shared 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.