Applicability to WebGPU buffer mapping

[kainino0x]

WebGPU is very interested in read-only ArrayBuffers (tracked here - thank you @erights for letting us know about it there!). So we are definitely interested in this proposal!

However, WebGPU's use-case is different, and we also need such ArrayBuffers to be detachable. In short, we need to give JS temporary read-only access to some section of memory. The reason to make it read-only is so that other system components (the GPU) can assume it hasn't been changed (avoiding flushing writes from JS and invalidating caches on the GPU).

Based on the README, I'm not sure exactly how important non-detachability is to this proposal. It mentions:

Why can't an immutable ArrayBuffer be detached/transferred?

Because that would result in observable changes to any TypedArray or DataView backed by it.

I believe this does not matter to the ROM use-case, however it does matter for the second use case:

APIs that accept ArrayBuffers and/or objects backed by them could also benefit from performance improvement by avoiding defensive copies when the input buffers are immutable

Hence whether Immutable ArrayBuffer actually needs a non-detachable guarantee (or mode) seems to depend heavily on whether this use-case is actually important, or obsoleted by the alternative solution mentioned:

(see Generic zero-copy ArrayBuffer usage for a proposed alternative solution to this problem in the Web Platform).

[Jack-Works]

Hi! A read-only view of a mutable underlying ArrayBuffer is one of the focus topics of https://github.com/tc39/proposal-limited-arraybuffer. Limited ArrayBuffer proposal will be discussed at the next tc39 meeting about the motivation update. If Immutable ArrayBuffer cannot fulfill this use case, maybe you can take a look at the Limited ArrayBuffer proposal.

[kainino0x]

We need to guarantee that the JS VM won't modify the memory at all, so read-only views of mutable ArrayBuffers are not suitable unless it's (1) impossible to access the mutable ArrayBuffer, while (2) still possible to make differently-typed ArrayBufferViews from whatever we return to the user. Most simply, returning a frozen ArrayBuffer would work, but it seems like that possibility is up in the air.