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.

[mhofman]

I believe the currently stated design goal of the limited array buffer proposal aligns with that

2. Read-only TypedArray/DataView to a read-write ArrayBuffer.
   1. Must not be able to construct a read-write view from a read-only view.

The main motivation for making Immutable ArrayBuffer non-detachable is so the TypedArray views on them can expose the indexed properties as non-writable and non-configurable. This is an important use case for the champions of this proposal. Without this there is no way to express to the holder of these views that the object they hold is truly immutable.

[Jack-Works]

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.

In WebGPU's case, the host API can return a read-only view where the underlying "mutable ArrayBuffer" is never exposed to the userland. In this case, no user code can modify it (and the engine also won't).

const view = context.getSomeGPUMemory()
// return a Uint8Array (read-only)
view.buffer // undefined

To "still possible to make differently-typed ArrayBufferViews from whatever we return to the user.", this works today, and it should continue working in a limited array buffer:

new Uint8Array(new Int8Array([-1]))
// a Uint8Array [255]

// by the way this does not work
new DataView(new Int8Array([-1]))

The main motivation for making Immutable ArrayBuffer non-detachable is so the TypedArray views on them can expose the indexed properties as non-writable and non-configurable.

Why do we need to expose them as non-writable and non-configurable? I think the Module Namespace-like behavior (exotic object, returns "writable") is good for this case.

[mhofman]

Why do we need to expose them as non-writable and non-configurable? I think the Module Namespace-like behavior (exotic object, returns "writable") is good for this case.

Because we need the holder of the object to be assured that any time it reads the indexed properties it will return the same value. A property being observably frozen is mainly for the consumer, so that the consuming code can build invariants it can rely upon.

The fact that a const export in a non-cyclic import is not visible as a non-configurable non-writable property on the module namespace object is something that bugs me for the same reason, and I sure don't want to use that as precedent.

[kainino0x]

To "still possible to make differently-typed ArrayBufferViews from whatever we return to the user.", this works today, and it should continue working in a limited array buffer:

new Uint8Array(new Int8Array([-1]))
// a Uint8Array [255]

I should have been more specific, we need it to be possible without a copy. Otherwise the benefit of using a read-only view (which lets us avoid copies) is negated. AFAICT (from the spec and Chrome's behavior) this makes a new Uint8Array by iterating over the Int8Array. Example:

> new Uint8Array(new Uint32Array([1, 2])).toString()
'1,2'
> new Uint8Array(new Uint32Array([1, 2]).buffer).toString()
'1,0,0,0,2,0,0,0'

// by the way this does not work
new DataView(new Int8Array([-1]))

This is something we would also want to work, zero-copy.

[Jack-Works]

I should have been more specific, we need it to be possible without a copy.

Yes, of course, the design goal of the limited array is (1) Give others an RO view of the ArrayBuffer and keep the RW internally. (2) Give others an RO or RW slice of the whole ArrayBuffer without giving access to the whole buffer.

In this issue, it fits (1), where the "RW" is never exposed and only kept by the WebGPU internal implementation.

[bakkot]

It's worth noting that WebAsssembly also has a use case for read-only views (see the first bullet of the "JS API Considerations" section). The "read-only constant data" use case could plausibly work with immutable buffers, but the "buffer backed by mapped data" or "buffer temporarily locked for use by web codes" use cases would need limited ABs, it sounds like.

[kainino0x]

@Jack-Works apologies, I misunderstood and though only the TypedArray object was readonly, but that you'd block access to typedarray.buffer to prevent getting the mutable version. I looked at the proposal again and I see that the ArrayBuffer itself is frozen and you have a readonly ArrayBuffer which is actually may be a view onto another read-write ArrayBuffer.

However we do still need detachability as mentioned in the first comment here, is that something that limited ArrayBuffer could do? Since it's "frozen" it kind of sounds like its size couldn't change. (Actually it also sounds like its contents couldn't change, but presumably that is not true if you can have read-only views on read-write ArrayBuffers.)

It's worth noting that WebAsssembly also has a use case for read-only views (see the first bullet of the "JS API Considerations" section). The "read-only constant data" use case could plausibly work with immutable buffers, but the "buffer backed by mapped data" or "buffer temporarily locked for use by web codes" use cases would need limited ABs, it sounds like.

BTW WebGPU is also very interested in being able to expose its (RO and RW) buffer mappings directly to Wasm, either via multiple Memorys or via "mmap" style memory control.

[Jack-Works]

However we do still need detachability as mentioned in the first comment here, is that something that limited ArrayBuffer could do?

I believe so, but it all depends on the engines (this may add too much complexity). The current proposal repo is out of date, and will be updated after the next meeting.