[js-api] Integration with the ResizableArrayBuffer and GrowableSharedArrayBuffer proposal

[syg]

The ResizableArrayBuffer and GrowableSharedArrayBuffer proposal is a TC39 proposal that is currently stage 2.

There was some discussion of how the proposal might integrate with the Wasm/JS API. It seems better to move the discussion here to get a concrete plan and to get more Wasm eyes on the issue.

As a starting point, I suggest the following changes to the WebAssembly.Memory API:

• Memory will have a new resizableBuffer attribute.
  • Returns a ResizableArrayBuffer or GrowableSharedArrayBuffer instance.
  • If an ArrayBuffer was vended by the buffer attribute on the same instance, that ArrayBuffer instance will be detached. SharedArrayBuffers and GrowableSharedArrayBuffer will alias the same memory.
  • If the Memory was created with a maximum size, that size will be reflected on the ResizableArrayBuffer or GrowableSharedArrayBuffer instance.
  • Otherwise, the maximum size is 2^32.
• Memory's buffer attribute will detach any ResizableArrayBuffer buffers vended by the resizableBuffer attribute.
• ResizableArrayBuffers gotten via Memory's resizableBuffer attribute will:
  • Throw on transfer(), since they can't be detached.
  • Throw on resize() calls that are shrinks.
  • Throw on resize() calls that are not in multiples of the wasm page size. (Thanks @conrad-watt)
• GrowableArrayBuffers gotten via Memory's resizableBuffer attribute will:
  • Throw on grow() calls that are not in multiples of the wasm page size.

Thoughts welcome.

(Also, what is the process for bringing such a "normative PR" that's not a full proposal to the CG? Is it just an agenda item?)

[syg]

cc @kripken for thoughts on the design for emscripten-generated code.

[conrad-watt]

The fields of the memoryDescriptor currently correspond precisely to the components of the type of the memory in core Wasm. Would it be acceptable for all memories to have a working resizableBuffer attribute added, rather than keying it off a new flag in the memoryDescriptor? Otherwise, there'd be an issue of how to handle memories that aren't directly created in JS, but are instead exported from a Wasm instance.

Also, there was some discussion that grow/resize would need to throw if grown by amounts which are not multiples of the Wasm page size, which seems fine.

It's great that this feature is being added to JS! To add more context for people here, I've linked below some pretty big toolchain/performance limitations Wasm has been dealing with which would be significantly helped by Resizable/GrowableArrayBuffer integration.
WebAssembly/design#1271
WebAssembly/design#1296

[syg]

Would it be acceptable for all memories to have a working resizableBuffer attribute added, rather than keying it off a new flag in the memoryDescriptor? Otherwise, there'd be an issue of how to handle memories that aren't directly created in JS, but are instead exported from a Wasm instance.

Ah, good point about non-JS-created memories. I don't have a strong opinion, it's more that I'm not sure how an always-available resizableBuffer attribute works. Vending a ResizableArrayBuffer/GrowableSharedArrayBuffer is mutually exclusive with vending a plain ArrayBuffer/SharedArrayBuffer. So if resizableBuffer is always there, is it a "treat whichever attribute is accessed first as the intended Buffer class to use"? That is, if I access resizableBuffer first, then afterwards accessing buffer would throw, and vice versa. That's a pretty weird API, but maybe it's fine?

[syg]

A third path would be another way to signal intent for what kind of buffer you want that's not on the MemoryDescriptor. I'm not fully clued in on the intent of the MemoryDescriptor, so that might be the wrong place to signal intent to begin with.

[conrad-watt]

Vending a ResizableArrayBuffer/GrowableSharedArrayBuffer is mutually exclusive with vending a plain ArrayBuffer/SharedArrayBuffer.

Does this have to be the case? Having the same Wasm memory backing both (e.g.) an ArrayBuffer and a ResizableArrayBuffer doesn't instinctively seem weirder to me than having an ArrayBuffer backed by a Wasm memory which is separately manipulated by Wasm operations. Presumably the ArrayBuffer would detach if the ResizableArrayBuffer ever calls resize, just as is already done for memory.grow in Wasm.

[syg]

I feel somewhat strongly that aliasing buffers like that on the JS side is a bad idea.

1. You're right that the buffer aliasing already exists for wasm-manipulated memory, but I feel like that's a pretty coarse-grained aliasing. It is still an invariant on the JS side that for non-shared buffers, if ta1.buffer !== ta2.buffer, their accesses can't alias. I'm pretty hesitant to break this invariant. It seems broadly useful for reasoning and source code transforms.

2. As you point out, resizes would require detaching all aliased non-resizable buffers (I guess there would just be a single one). This is extra complexity in implementations and spec that I think would be harmful.

Edit: Contra to #1292 (comment), I guess I do have a strong opinion if the two attributes are supposed to vend aliased-backing-store buffers. :P

[conrad-watt]

In that case something like #1292 (comment) does seem like the immediate path of least resistance, although if buffer aliasing were to sneak into JS through some other avenue, I'd hope we could relax the throwing behaviour.

[conrad-watt]

Alternatively, maybe the first vend of aResizableArrayBuffer could permanently detach the associated ArrayBuffer (including subsequent results of .buffer), while vending a GrowableSharedArrayBuffer is just allowed to alias with the associated SharedArrayBuffer, since consecutive accesses to .buffer of a shared memory can already give aliasing buffers (e.g. if there is a concurrent growth).

[syg]

Cool, I like the suggestion in #1292 (comment).

[conrad-watt]

With reference to the OP...

• If the Memory was created with a maximum size, that size will be reflected on the ResizableArrayBuffer or GrowableSharedArrayBuffer instance.
• Otherwise, some implementation-defined max size will be reflected.

If I'm interpreting the JS proposal correctly, it's mandatory to provide a maximum size, but grow/resize is still allowed to fail arbitrarily even before reaching the max size, analogous to our memory.grow. In Wasm, a memory's max size is optional, but there's still a hard limit of 2^32 bytes, so from a purely semantic standpoint it would make sense for this to be the observable max in JS for a Wasm memory with no explicit max, rather than leaving it to be implementation-defined (especially if JS were to ever allow buffers larger than this in other contexts).

Since growth can fail even for sizes below this, there's no issue in abstract, but would this approach mess with any engine/code heuristics?

EDIT: there was a time when engines aligned on a hard limit of 2^31 bytes for memories, below the theoretical maximum. I interpreted the "implementation-defined" line of the OP more broadly, but is the intention of this line just to allow for a static limit like this to be exposed?

[syg]

so from a purely semantic standpoint it would make sense for this to be the observable max in JS for a Wasm memory with no explicit max, rather than leaving it to be implementation-defined (especially if JS were to ever allow buffers larger than this in other contexts).

That makes sense to me, I'll update the OP.

Since growth can fail even for sizes below this, there's no issue in abstract, but would this approach mess with any engine/code heuristics?

The engine implication to me is that Wasm memory-backed buffers need special casing. But they do already for special detachment semantics, special resize semantics, etc, so this seem to me that it'll add any more.

[conrad-watt]

That makes sense to me, I'll update the OP.

Just to be clear, after some pondering I think that it makes sense for the length in this case to be implementation defined up to any static limit that engines set on memory size which is lower than the spec max. For example, this used to be 2^31, is now moving to 2^32 (in line with the spec limit), and when we get 64-bit memories, may be somewhat lower than 2^64.

Generally we've tried to have all Web engines agree to align on such a value, where it's necessary, but it's not documented as part of the "core spec".

EDIT: the value is in fact fixed by the JS API, so that should be the number used for the max field. No need to say it's implementation defined after all!

[syg]

when we get 64-bit memories, may be somewhat lower than 2^64.

Oh, that's gonna be a tricky thing on the JS side. ArrayBuffer sizes aren't BigInts, nor can BigInts be property keys currently.

[syg]

EDIT: the value is in fact fixed by the JS API, so that should be the number used for the max field. No need to say it's implementation defined after all!

I'm reading that as 2^32 (max 65536 pages * 65536 byte page size), yeah?

[conrad-watt]

Oh, that's gonna be a tricky thing on the JS side. ArrayBuffer sizes aren't BigInts, nor can BigInts be property keys currently.

AFAIK we haven't explicitly discussed JS integration for the memory64 proposal yet, but that might be something that @aardappel can comment further on at some point.

I'm reading that as 2^32 (max 65536 pages * 65536 byte page size), yeah?

That's my reading 🎉

(Also, what is the process for bringing such a "normative PR" that's not a full proposal to the CG? Is it just an agenda item?)

BigInt integration (which IIUC was also purely a JS-API change) was handled as a regular proposal, but IIRC it moved through the phases very quickly because there were no core spec changes. Unless anyone comes up with objections here (@kripken dropped a 👍 above) it probably makes sense to add this to the agenda as a poll for phase 1. BigInt integration was proposed quite early on in the life of the committee so people may want to bikeshed a revised procedure for JS-API changes going forward.