SharedArrayBuffer.grow(amount) has different semantics to WebAssembly.Memory.grow(amount)

[juj]

In the proposal,

class SharedArrayBuffer {
  ...
  // Throws a RangeError unless
  ...
  // this.byteLength <= newByteLength <= this.maximumByteLength.
  ...
  grow(newByteLength);

i.e. grow is interpreted to take the new byte length.

WebAssembly.Memory.grow() is instead specced to specify how much to grow by, i.e. the value is not interpreted as the new absolute size, but how much to add to the existing size (an increment).

I wonder if it would make sense to use the same interpretation as WebAssembly.Memory.grow()?

Although WebAssembly.Memory.grow() deals in pages and not in bytes. What would happen with

let m = new WebAssembly.Memory({ initial: 1, maximum: 10, shared: true});
let sharedArrayBuffer = m.buffer;
sharedArrayBuffer.grow(65536 + 32767);
// WebAssembly.Memory() is now 1.5 pages long?

?

One way to resolve this might be to make SharedArrayBuffer.grow() simply throw if the grow is not a multiple of 64KB, when the SAB was derived from a WebAssembly.Memory?

[conrad-watt]

One way to resolve this might be to make SharedArrayBuffer.grow() simply throw if the grow is not a multiple of 64KB, when the SAB was derived from a WebAssembly.Memory?

I believe this is the current proposed semantics (see WebAssembly/spec#1300).

[syg]

@conrad-watt is correct. The spec draft has host hooks in place (the one you care about is HostGrowSharedArrayBuffer) for WebAssembly to apply its own checks as necessary, much like how WebAssembly-vended buffers cannot be detached per normal.

[syg]

The conclusion here is that the semantics as proposed are the same, so closing.