Depending on the target platform, GPUBuffer mapping may be implemented using one or more buffer allocations. There may be a single allocation which is addressable both by JavaScript and the GPU, or there may be multiple allocations where the WebGPU implementation inserts copies between intermediate staging allocations to allow JavaScript to read/write GPU data. The implementation may need to use intermediate staging allocations if VK_EXT_external_memory_host or ID3D12Device3::OpenExistingHeapFromFileMapping method is not available.

Today, creating a GPUBuffer may generate an asynchronous out-of-memory error if allocation of the buffer fails. Proposal: Because on some platforms, the mapping itself is one or more additional allocations, it should be permissible for mapping the buffer to fail due to an out-of-memory error. If an out of memory error occurs, then GPUBuffer.getMappedRange returns null (or perhaps an empty ArrayBuffer).

Returning the error in GPUBuffer.getMappedRange means that the call to GPUBuffer.mapAsync must have succeeded. i.e. it should not be possible to have an out-of-memory error both on buffer creation and on buffer mapping, because OOM on buffer creation means the mapAsync promise would reject and the call to getMappedRange would be invalid.

Alternatives:

• Reject the mapAsync Promise. This doesn't feel quite right because calling mapAsync signals the intent to map a buffer, but the script doesn't actually receive the mapped buffer allocation until calling getMappedRange. Further, the script may request getMappedRange for a smaller portion than the range passed into mapAsync. The implementation may defer allocation until the call to getMappedRange.
• Throw an exception in getMappedRange. Exceptions usually indicate a programming error due to invalid usage of the API. An out-of-memory condition is not invalid usage of the API.