Detaching ArrayBuffers which came from WebAssembly Memory objects should throw

[littledan]

I'm working on formalizing the WebAssembly/JavaScript API at WebAssembly/spec#591 . WebAssembly provides WebAssembly.Memory objects, which are the JavaScript interface to the backing heap. You can get the underlying ArrayBuffer using the WebAssembly.Memory.prototype.buffer getter, but detaching this ArrayBuffer should throw a TypeError. The question is where to throw the error--it's thrown from JavaScript, and should be included in all embedding environments, not just HTML, so I hope we can put this error in the JavaScript spec. I'll follow up with a PR, but filing this bug as a placeholder.

[annevk]

It's not possible to throw in HTML without modifications to the ArrayBuffer object done in JavaScript. (Once you pass memoryInstance.buffer the HTML serialize algorithm doesn't know that ArrayBuffer object came from a Memory object.)

[annevk]

It's not possible to throw in HTML without modifications to the ArrayBuffer object done in JavaScript. (Once you pass memoryInstance.buffer the HTML serialize algorithm doesn't know that ArrayBuffer object came from a Memory object.)

[littledan]

@annevk We have to mark the data block or ArrayBuffer somehow; the JavaScript spec currently doesn't know that it came from Wasm either. Once it's marked, I think either spec could check for this marking and throw appropriately. The killer argument for me is that we need to throw in any embedding environment (including Node.js).

[littledan]

@annevk We have to mark the data block or ArrayBuffer somehow; the JavaScript spec currently doesn't know that it came from Wasm either. Once it's marked, I think either spec could check for this marking and throw appropriately. The killer argument for me is that we need to throw in any embedding environment (including Node.js).

[annevk]

Makes sense. It might also be beneficial for JavaScript to expose a way to get a non-detachable ArrayBuffer object as implementations can probably optimize that even better due to lack of branching. However, maybe SharedArrayBuffer objects are good enough for that already as long as you're careful.

[annevk]

Makes sense. It might also be beneficial for JavaScript to expose a way to get a non-detachable ArrayBuffer object as implementations can probably optimize that even better due to lack of branching. However, maybe SharedArrayBuffer objects are good enough for that already as long as you're careful.

[littledan]

Spec layering doesn't necessarily match implementation layering here. For example, some JS implementations have special support for HTML's funny global object behavior.

[littledan]

Spec layering doesn't necessarily match implementation layering here. For example, some JS implementations have special support for HTML's funny global object behavior.

[lars-t-hansen]

It would be good not to encourage casual use of SharedArrayBuffer, if we can avoid it; at least not yet.

(In Firefox we currently mmap at least two pages for any SAB, and may reserve much more, on the assumption the SAB will be used for backing storage by asm.js. Were it not for that we could do better, but as it is it is fairly expensive, not least because the OS restricts the max number of simultaneous mappings and having a lot of small SABs may force premature GC.)

[lars-t-hansen]

It would be good not to encourage casual use of SharedArrayBuffer, if we can avoid it; at least not yet.

(In Firefox we currently mmap at least two pages for any SAB, and may reserve much more, on the assumption the SAB will be used for backing storage by asm.js. Were it not for that we could do better, but as it is it is fairly expensive, not least because the OS restricts the max number of simultaneous mappings and having a lot of small SABs may force premature GC.)

[littledan]

I don't see how SharedArrayBuffer would relate to a solution here. You can't detach a SharedArrayBuffer.

[littledan]

I don't see how SharedArrayBuffer would relate to a solution here. You can't detach a SharedArrayBuffer.

[rossberg]

Quoting my earlier comment on WebAssembly/spec#591 here for easier reference:

One way I envision such detachment restrictions could be spec'ced in Ecma262 in a generic and safe fashion is by adding a notion of optional temporal ownership for array buffers. Specifically:

• Every ArrayBuffer has an internal field [[Owner]], which is either undefined or an ownership token.
• Ownership tokens are spec-level generative entities (could be represented by symbols).
• There is an abstract OwnArrayBuffer function that takes a buffer and returns a new ownership token. It sets [[Owner]] to the same token. If it was set already, an Error is thrown.
• There is an inverse DisownArrayBuffer function that takes a buffer and a token and sets [[Owner]] back to undefined iff the passed token matches its current value. Otherwise it throws.
• DetachArrayBuffer checks [[Owner]] and throws if it is not undefined.

The token is a form of capability that defines ownership and is required as proof to return that ownership (and thereby allowing detaching the buffer).

[rossberg]

Quoting my earlier comment on WebAssembly/spec#591 here for easier reference:

One way I envision such detachment restrictions could be spec'ced in Ecma262 in a generic and safe fashion is by adding a notion of optional temporal ownership for array buffers. Specifically:

• Every ArrayBuffer has an internal field [[Owner]], which is either undefined or an ownership token.
• Ownership tokens are spec-level generative entities (could be represented by symbols).
• There is an abstract OwnArrayBuffer function that takes a buffer and returns a new ownership token. It sets [[Owner]] to the same token. If it was set already, an Error is thrown.
• There is an inverse DisownArrayBuffer function that takes a buffer and a token and sets [[Owner]] back to undefined iff the passed token matches its current value. Otherwise it throws.
• DetachArrayBuffer checks [[Owner]] and throws if it is not undefined.

The token is a form of capability that defines ownership and is required as proof to return that ownership (and thereby allowing detaching the buffer).