New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detaching ArrayBuffers which came from WebAssembly Memory objects should throw #1024

Closed
littledan opened this Issue Oct 26, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@littledan
Member

littledan commented Oct 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 26, 2017

Contributor

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.)

Contributor

annevk commented Oct 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Oct 26, 2017

Member

@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).

Member

littledan commented Oct 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 26, 2017

Contributor

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.

Contributor

annevk commented Oct 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Oct 26, 2017

Member

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

Member

littledan commented Oct 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@lars-t-hansen

lars-t-hansen Oct 26, 2017

Contributor

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.)

Contributor

lars-t-hansen commented Oct 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Oct 26, 2017

Member

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

Member

littledan commented Oct 26, 2017

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

@rossberg

This comment has been minimized.

Show comment
Hide comment
@rossberg

rossberg Oct 26, 2017

Member

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).

Member

rossberg commented Oct 26, 2017

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment