Review

[syg]

Informative

• I plan to bring this proposal up at the Wasm CG meeting next week to get Wasm's take. I think this is orthogonal and does not step on Wasm's toes. There is an interesting future design question for reflecting WasmGC Arrays of scalars as JS TypedArrays. I imagine those reflections will not have detachable buffers, but still warrants some discussion with the CG.

Normative

• DetachArrayBuffer needs to throw for immutable buffers.
  Validate mutability in DetachArrayBuffer #38
• Please have a reviewed PR against HTML for structured clone. I don't think there's much design space here, so I'm personally happy for this to be a stage 3 blocker instead of a stage 2.7 blocker. But should WHATWG give feedback that requires this proposal to change, we'd need to make normative changes during 2.7.
  Add immutable array buffer awareness to structuredClone whatwg/html#11033
• I'd love to implement this with mprotect. However, that requires page alignment. We can't reveal the page size to user code, as that's a fingerprinting vector. Fixing a page size seems too unergonomic. Ideas? (Using mprotect is a nice-to-have for V8, not a requirement.)

Editorial

• Prefer ValidateTypedArray's use argument be renamed accessMode. Ditto for the other Validate AOs.
  Editorial: Improve/explain operation parameter names #33
• Rename [AllocateArrayBuffer]'s maxByteLength parameter to something more descriptive since it can be IMMUTABLE. (I suppose you're minimizing the diff for now?)
  Editorial: Improve/explain operation parameter names #33

[bakkot]

For structured clone, see some discussion in #19.

[erights]

@syg for our own convenience making progress on your suggestions, I've turned your bullets in check boxes. I also turned the first paragraph into a checkbox, but it sounds like something you're queueing for yourself do. Yes?

[syg]

but it sounds like something you're queueing for yourself do. Yes?

Yep, planning to do it myself.

[erights]

On mprotect point, I agree that there's probably no reasonable way to expose its full power to JS. However, this proposal is consistent with an implementation strategy that makes use of the mmu internally, and so exposes a bit of its power. Whether that is better than nothing is not for me to judge.

My assumption: there will be many small immutable buffers, and many huge ones. Any use of the mmu is probably only worth it for the huge ones, but those are more likely to be the ones where micro performance matters.

• An implementation could choose to allocate a huge immutable buffer on a set of pages shared with nothing else. (It would probably also page align this allocation, but that's besides my current point). Obviously, it would write protect these pages. This has two potential benefits:

  • It might avoid the need to test an additional bit during attempted writes, instead catching the page fault and turning it into the right thrown error.
  • Even if treatment of invalid writes happens without the optimization above, this write-protection is belt-and-suspenders. This is especially important when the same immutable array buffer is shared between different agents and different languages. Otherwise, a weakness in any one of these language implementations in any of these agents threatens all.

• Even when talking between different processes, each with their own address space, for a huge enough buffer it will be cheaper O(logN) to map it into both address spaces than to copy it O(N). IOW, zero-copy even between address spaces.

Although I don't believe any of these optimization opportunities should affect whether this proposal advances, I'd love to hear from implementors whether any of these are practical. Thanks.

[gibson042]

@syg All concerns have been addressed (see new links above).

[erights]

Hi @ricea

At w3c/webtransport#131 (comment) @domenic suggests you may be interested in this topic: #30 (comment) above. I look forward to your comments. Thanks!