List of issues to discuss with TC39, WASM, JS engine teams

[kainino0x]

• mmap'ing ArrayBuffers into WASM heap
• read-only ArrayBuffers and write-only ArrayBuffers (that work with mmap)
• ArrayBuffers (non-Shared, same thread) that point at non-disjoint ranges of the same backing data
• ArrayBuffers whose base addresses aren't maximally-aligned (e.g. Float64Array not valid at offset 0, valid at offset 4)
  • No one has asked for this yet, probably not very important
• "bitflags" equivalent functionality (e.g. Java-style EnumSet 🥺)
• Ability to make ArrayBuffers non-transferrable EDIT: It turns out this already exists as [[ArrayBufferDetachKey]]
• SharedObjectTable a bit like SharedArrayBuffer but instead of containing bytes, they contain references to shallow-cloneable objects ([Serializable] IDL interface objects). This should allow for example for GPUTextures created on one worker to be instantly visible to other workers.
  • Or (somewhat less ideal) synchronous receiveMessage() on MessagePort. (WASM multi-threading ability #476)
  • Place to draft a proposal: https://hackmd.io/@webgpu/S1f56dN8s

Please add more issues on this thread.

[kainino0x]

• Non-transferable ArrayBuffers (mapped ArrayBuffers shouldn't be transferable to other threads). (We can do this without JS changes by faking transfers, by making them actually copies instead.)

[Kangz]

• SharedObjectTable a bit like SharedArrayBuffer but instead of containing bytes, they contain references to shallow-cloneable objects ([Serializable] IDL interface objects). This should allow for example for GPUTextures created on one worker to be instantly visible to other workers.

[kainino0x]

• Or (somewhat less ideal) synchronous receiveMessage() on MessagePort.

#476

[sandersdan]

WebCodecs is also interested in read-only ArrayBuffers, for providing access to YUV planes in CPU memory that remain owned by decoders. Is there any previous work on this request?

[kainino0x]

A discussion on the internal-gpu mailing list can be found here:
https://lists.w3.org/Archives/Member/internal-gpu/2020May/0001.html
in which Ken discusses Java's past experience with read-only ArrayBuffers.
I just forwarded it to you, @sandersdan.

Other discussions I just found:

• https://webbluetoothcg.github.io/web-bluetooth/#read-only-arraybuffer (cc @reillyeon @odejesush)
  • read-only ArrayBuffer is strange WebBluetoothCG/web-bluetooth#300
• https://github.com/tc39/proposal-readonly-collections

[kainino0x]

• Re-pointing an existing ArrayBuffer wrapper to a new backing store (to avoid garbage) (EDIT: ResizableArrayBuffer proposal would allow us to achieve this)

[kainino0x]

• Detachable SharedArrayBuffer, for mapping a buffer and then accessing the mapping from multiple threads

[kainino0x]

• SharedObjectTable a bit like SharedArrayBuffer but instead of containing bytes, they contain references to shallow-cloneable objects ([Serializable] IDL interface objects). This should allow for example for GPUTextures created on one worker to be instantly visible to other workers.

It turns out that this (or synchronous receive-message) would also be extremely useful to WebAssembly for sending modules around for dynamic linking.

[Kangz]

Another important thing to discuss with TC39 is adding a concept of non-transferrable ArrayBuffer. Right now this group agreed to make the result of GPUBuffer.getMappedRange non-transferrable so we can detach them on GPUBuffer.unmap but the JS spec doesn't have any way to express this at the moment.

Contrary to the other TC39 topics in this issue, this one is important to figure out before WebGPU v1 as it is an important part of the WebGPU semantics (and not a future improvement).

[Kangz]

This might also require a change to the HTML spec for structuredSerializeWithTransfer (an internal postMessage algorithm)

[kainino0x]

As mentioned above:

• Non-transferable ArrayBuffers (mapped ArrayBuffers shouldn't be transferable to other threads). (We can do this without JS changes by faking transfers, by making them actually copies instead.)

We might be able to make this work entirely within our spec instead of having to go change the behavior of ArrayBuffer. In more detail:

If you tried to transfer a getMappedRange-created ArrayBuffer, it would appear to work entirely normally - old ArrayBuffer would get detached - except the underlying data would get copied into a new, run-of-the-mill ArrayBuffer, which means that any writes to the new ArrayBuffer would not appear in the GPUBuffer upon unmap().

[kainino0x]

Filed new issue #2072.

[pythonesque]

AFAIK, what you're describing is the behavior for non-transferable objects, though? Minus the fake detach, that is. I guess the point is that this wouldn't be an observable behavior change compared to the usual behavior (except in the context of WebGPU memory mapping, which isn't specified by TC39)?

[kainino0x]

Replied in #2072 (comment)

[jimblandy]

If you tried to transfer a getMappedRange-created ArrayBuffer, it would appear to work entirely normally - old ArrayBuffer would get detached - except the underlying data would get copied into a new, run-of-the-mill ArrayBuffer, which means that any writes to the new ArrayBuffer would not appear in the GPUBuffer upon unmap().

I think this would still be considered a change to JS. You've got this thing called an ArrayBuffer, but it's not behaving like one.

[kainino0x]

It does behave like an ArrayBuffer in every way relevant to JS. When you transfer an ArrayBuffer in JS, you can't tell whether it's copied or moved because there is no way to observe that. WebGPU provides a way to observe it for these specific ArrayBuffers, because they're views into some memory owned by WebGPU. The difference is really that WebGPU observes writes before the transfer, and it doesn't observe them afterward.

Thinking about it this way, perhaps the way I specced it sounds more intrusive to the ArrayBuffer spec than it should. I'll look at whether I can make that better.

[kainino0x]

This proposal might be a step toward a SharedObjectTable like thing:
https://github.com/tc39/proposal-structs

[kainino0x]

triage: This is just a tracking issue and nothing here is required for V1 since we don't have multithreading, and have resolved our buffer-mapping-detach problem.