[js-api] Integrate with the ResizableArrayBuffer proposal

[syg]

Closes #1292

This PR integrates the resizable buffers proposal with js-api.

Example use of the proposed API:

// mem is a WebAssembly.Memory
let ab = mem.buffer;
assert(!ab.resizable);

// Make .buffer resizable, detaching the old one.
let rab = mem.toResizableBuffer();
assert(rab.resizable);
assert(mem.buffer === rab);
assert(%IsDetached(ab));

// We can go back if we choose.
let ab2 = mem.toFixedLengthBuffer();
assert(!ab2.resizable);
assert(mem.buffer === ab2);
assert(ab2 !== ab);
assert(%IsDetached(rab));

// Let's go back to resizable. Memory#grow no longer detaches .buffer when it's resizable.
rab = mem.toResizableBuffer();
let oldLen = rab.byteLength;
mem.grow(8);
assert(!%IsDetached(rab);
assert(rab.byteLength === oldLen + (8 * 65536))

// RAB#resize throws when trying to shrink or grow by non-page multiples for WebAssembly.Memory-vended RABs.
assertThrows(() => rab.resize(rab.byteLength - 65536), RangeError);
assertThrows(() => rab.resize(rab.byteLength + 10), RangeError);

[littledan]

This proposed integration looks great to me. I like the API shape and the semantics of when and how rounding happens.

I'm happy to see proposals move through WebAssembly CG's process in the form of a PR, which seems more clear and lightweight than the whole-repository fork.

Have we heard feedback from SpiderMonkey or JSC about this PR? cc @lars-t-hansen @kmiller68

[littledan]

Nit: I think of host hooks as being uniform across the agent. Maybe it makes more sense to use an internal slot where hosts can write a method, rather than a host hook, if this varies per instance.

Anyway, the idea that the Wasm ResizableArrayBuffers round up to the next Wasm page when you grow them (and invoke the "grow the memory buffer" algorithm) sounds perfect to me!

[syg]

That's an interesting idea for hosts to write a method. It'll be a new editorial convention.

Do I understand the nit correctly that you see this as an implementation hook instead of a host hook, thus the suggestion?

[syg]

Thanks for the review.

[syg]

That's an interesting idea for hosts to write a method. It'll be a new editorial convention.

Do I understand the nit correctly that you see this as an implementation hook instead of a host hook, thus the suggestion?

[rossberg]

@syg, this PR is stale, do you still intend to land it?

[syg]

I do, yes, but it's not clear to me when I should be doing that. This PR is phase... 3, I think? How should integration PRs like this land? My recollection is that we're waiting for the upstream JS feature to get into the JS standard (i.e. stage 4), which hasn't happened yet.

[dtig]

We discussed this in the 6/22/21 meeting, though the meeting notes aren't very verbose. What I remember matches @syg's comment above that as this is an integration feature, we do need this to be standardized in TC39, before this is merged into the Wasm spec. The plan for this specifically is that once the JS feature lands, this comes back to the Wasm CG for a final poll, and can land with edits if needed.

[dtig]

I'd like some input on the usage patterns of this API in the tools. One of the motivations of the ResizableArrayBuffer proposal is to expose memory.grow to JS without having to detach the existing ArrayBuffer. If a Wasm instance has a "default" buffer associated with it, to ensure that it doesn't detach on Grow it stands to reason that it should be a ResizableArrayBuffer. The change that this PR makes is that the buffer getter returns a fixed length ArrayBuffer (which makes sense for backwards compatibility). My question here is how would tools use this API? Is the expectation that applications would use toResizableBuffer in place of the buffer getter?

On a side note, this proposal also needs a similar PR to the threads repository to integrate GSABs with shared Wasm memory.

[rossberg]

Has there been any progress on this?

[syg]

@rossberg My understanding is there's discussion on whether it's okay for the wasm spec to depend on JS proposals that aren't yet merged into ecma262. The status quo is no, so I've been conservative and letting this sit open until we get resizable buffers to stage 4 in TC39.

Currently the proposal is stage 3 in TC39. Chrome has shipped in M111, and I see Safari enabled it in STP 160. I can probably ask for stage 4 soon, but the practical upshot it's stable and shipped and there shouldn't be too much risk for the wasm spec to depend on it even during stage 3.

Edit: Of course there are mechanical issues with depending on a stage 3 TC39 proposal. The wasm spec document would need to normatively reference spec drafts instead of the official living spec, etc.

[rossberg]

@syg, makes sense, thanks for the update!

[syg]

@conrad-watt Could you give me an overview of what needs changing on the threads proposal to account for resizable buffers? (Or, if I'm really feeling lucky, are you up for making the changes?)

[conrad-watt]

I'm happy to take a look at this myself, but I'm currently working through a rebase of the threads repo (with thanks to @ioannad!) which I'd prefer to finish first. Is it ok if I get back to you in ~2 weeks?

Looking at the language in the current draft threads JS API, my knee-jerk feeling is that growable SharedArrayBuffer integration won't be too difficult an extension, so long as I can crib from this PR.

[syg]

@conrad-watt 2 weeks sgtm! I'm getting ready to ask for Stage 4 for resizable buffers so crossing my t's and dotting my i's.

[conrad-watt]

Ok, I have a fresh version of the threads specification now living in a branch. @syg I'll spend a few days looking at growable SharedArrayBuffer and see what I can do (although I'll probably end up begging for help at some point).

Just as a very surface-level question, is the intention that growable buffers will be produced by toResizableBuffer on a shared memory, or will there be a separate toGrowableBuffer method for shared memories? I have a slight knee-jerk preference for the former.

[syg]

Ok, I have a fresh version of the threads specification now living in a branch. @syg I'll spend a few days looking at growable SharedArrayBuffer and see what I can do (although I'll probably end up begging for help at some point).

Excellent! I'd be happy to do work here as well but I'd need handholding around the Wasm spec.

Just as a very surface-level question, is the intention that growable buffers will be produced by toResizableBuffer on a shared memory, or will there be a separate toGrowableBuffer method for shared memories? I have a slight knee-jerk preference for the former.

The intention was for the former IIRC. The latter might have made more sense in the first iteration of the proposal, where ResizableArrayBuffer and GrowableSharedArrayBuffer had different JS types. But the current iteration keeps them as ArrayBuffer and SharedArrayBuffer so one getter makes more sense IMO.

[conrad-watt]

Just a note here that we should probably keep an eye on tc39/ecma262#3116

[Ms2ger]

This is not great - I think we should have a global HostResizeArrayBuffer definition, which checks if its buffer argument is one of these special buffers - I guess we could even use [[ArrayBufferDetachKey]] for that

[bakkot]

The JS proposal has landed in the JS specification, with implementations shipping in Chrome and Safari and IIRC underway in Firefox.

[ioannad]

@Ms2ger does the last commit address your review comment?

[Ms2ger]

Thanks, just some minor comments.

[rossberg]

@syg, can you address @Ms2ger's remaining comments, so that we can merge this?

[syg]

I think @ioannad would better handle it, as she's been handling @Ms2ger's previous reviews. Sorry to pass the buck. :)

[castholm]

@Ms2ger I'm just an outside observer so apologies if I'm stating the obvious, but I wanted to point out that this was merged into the master branch and not main, so as a result the linked issue was not closed and the updated spec was not deployed to https://webassembly.github.io/spec/.

[Ms2ger]

Argh. I opened #1742, but of course now I can't approve it, because I opened it. Thanks for flagging!